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/
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/
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/
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/
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/
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/
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/
random ramblings on 8xx patches (long and tedious :-)
i'd like to clarify a number of things regarding potential 8xx patches, ask some questions, make some observations, etc. (poor wolfgang has already seen much of this via private e-mail so i expect he'll skim it, if that. i'm still working thru his replies so i'll be repeating some of the stuff i already sent him.) What's a patch? - from the mpc850 family user's manual, i have the parameter RAM memory map table (USB, I2C, SCC2, SPI, and so on), and it's clear that a major purpose of patching is to relocate some of these areas elsewhere in DPRAM by patching the microcode (did i phrase that correctly?) in our case, we need to relocate SMC1 so we can use SCC3 for ethernet, and we already have that working under an ancient 2.4.22 kernel so, yes, we've succesfully applied a patch. does that completely cover the definition of a patch? an array of hex values to be written to, say, 2000, or 2f00 (or elsewhere)? and strictly for the purposes of parameter relocation? if not, what else would fall under the definition of patch that should be available to the developer? How many potential patches are there? - currently, in the latest bk pull, there is only one patch selection option: I2C/SPI Microcode Patch. but clearly there are other choices. even though that's the only selection listed in the config menu, if you look at micropatch.c, there's mention of an SMC patch (which you can apparently get only by editing the file, not by just selecting an option). there's also reference to a USB SOF patch. why wouldn't these also be listed in the kernel config menu? it seems misleading to display a choice for only a single patch when, in fact, there are *clearly* others (specifically, SMC1 relocation to use SCC3 for ethernet which is the one we need although, admittedly, that's kind of specialized). rather than that single selection in the MPC8xx CPM Options, it would make far more sense to have *all* patches listed as subentries under a patch menu, like: MPC8xx CPM Patches -- akin to top-level config menu entries like: Device drivers -- File systems -- and so on, with mutually-exclusive patches deactivating one another as they're selected. to present the user with a single I2C/SPI patch option is just silly. What's the limit on patches? again, based on my reading, it seems clear that you can apply only a limited number of patches, as each patch appears to require a certain number of traps in micropatch.c for example, if you want to apply the SMC patch, there's this excerpt in micropatch.c: /* Enable the traps to get to it. */ commproc-cp_cpmcr1 = 0x8080; commproc-cp_cpmcr2 = 0x808a; commproc-cp_cpmcr3 = 0x8028; commproc-cp_cpmcr4 = 0x802a; similarly, if you want the IIC patch: /* Enable the traps to get to it. */ commproc-cp_cpmcr1 = 0x802a; commproc-cp_cpmcr2 = 0x8028; commproc-cp_cpmcr3 = 0x802e; commproc-cp_cpmcr4 = 0x802c; which suggests that not only are the SMC and IIC patches mutually exclusive, once you pick either one, you're finished in terms of applying other patches. is that accurate? (interestingly, there's nothing in micropatch.c that forces those two patches to be mutually exclusive. since IIC occurs further down in the file, it would apparently override the earlier SMC patch. not good.) and what about the USB patch? at first glance, it doesn't appear to require any traps, but it does set commproc-cp_rccr, so does that make it mutually exclusive with IIC and SMC patches? in short, it would be useful to know: * what's the definition of a patch? * what are the list of possible patches? * what are the resources required for a patch to be applied, and what are the consequences for patch co-existence? The I2C/SPI patch - perhaps showing my unbounded ignorance but, given that the parameter RAM memory map table shows different addresses for I2C and SPI, respectively, is it feasible to relocate one and not the other? why does all the literature i read insist on referring to the *combined* I2C/SPI patch? just curious. would there be any value in relocating just one and, if you could, would that cost only two traps, leaving open the possibility of another patch? The USB SOF patch - apparently, the onboard USB on the 850 is somewhat flaky, which is why the USB SOF patch isn't even selectable in micropatch.c, is that it? note the excerpt from micropatch.c #ifdef CONFIG_USB_MPC8xx #define USE_USB_SOF_PATCH #endif a recursive grep shows that there's nothing in the entire kernel source tree that even defines CONFIG_USB_MPC8xx, so that patch is pretty well a non-issue. (side note: apparently, up to rev. b of the processor had this problem. we are using rev. c which allegedly has fixed the problem, but rev. c is not
random ramblings on 8xx patches (long and tedious :-)
On Thu 7/22/2004 8:00 AM, rday wrote: apparently, the onboard USB on the 850 is somewhat flaky, which is why the USB SOF patch isn't even selectable in micropatch.c, is that it? I've been working in the background for over a year now to get the host-mode USB interface working on our custom '850 hardware (running vxworks (unfortunately)). The problem is not so much that the USB controller is flakey, it does what it does quite reliably. The real problem is that the MPC850 USB controller was designed for target-mode applications and not host-mode applications. Host-mode in the MPC850 is, at best, an after-thought. At the implementation level, there are (at least) two major problems: 0. The MPC850 USB controller is neither of the popular USB 1.1 implementation models (UHCI or OHCI). Since the controller is really an SCC implemented in microcode in the CP, it has buffer descriptors (BDs) rather than transfer descriptors (TDs). Further, it doesn't do any of the tree-walking that a proper [UO]HCI does. It's pretty ugly if you're trying to use a manufacturer-supplied driver. 1. The USB spec. says that the start of frame (SOF) pulse must be sent within +/- 500 nanoseconds of the beginning of every 1 msec. frame interval. There is no provision in the MPC850 hardware to do this automatically and it's simply impossible to get anywhere close to this timing with software. I haven't timed it, but I suspect the microcode patch has trouble meeting this spec. as well. It does get a whole lot closer than a software-only solution, though. There's a bunch of other detailed problems that I won't bore everyone with. Bottom line: Don't expect too much out of the MPC850 USB controller in host-mode. Regards, Charlie ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
random ramblings on 8xx patches (long and tedious :-)
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. Host-mode in the MPC850 is, at best, an after-thought. That's true. Having been a part of the early development of all of the 8xx parts, there were lots of requirements that changed once the parts hit the street. 0. The MPC850 USB controller is neither of the popular USB 1.1 implementation models (UHCI or OHCI). It's not the only one. I think there are more embedded controllers that are not UHCI/OHCI than those that are. Since we work in the source code world, it hasn't really been much of a problem. . I haven't timed it, but I suspect the microcode patch has trouble meeting this spec. as well. It does get a whole lot closer than a software-only solution, though. The microcode patch works quite well. There's a bunch of other detailed problems that I won't bore everyone with. Bottom line: Don't expect too much out of the MPC850 USB controller in host-mode. 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. I'm never surprised when I plug something in to any kind of system and it doesn't work. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
random ramblings on 8xx patches (long and tedious :-)
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. -Matt ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
