Zach, There are a few things missing on your list which I think are important:
- Coldfire support (which is basically an enhanced 68000 core) would be nice. There is no open source solution out there to program Coldfire controllers which is a shame because the Coldfire controllers are actually quite nice and reasonably priced. Freescale thinks their customers should use Codewarrior or take their business somewhere else. - Completing ARM Cortex A8 support. I see CFI is on your list as well. I have a slightly improved version of cfi.c which some speed enhancements. Shall I mail it to you to have a look at it? I agree the cfi code is not very clean; a lot of code which basically does the same is duplicated. Also the bus width / chip width handling is not fully implemented yet. IMHO vendor specific code could be just a bunch of functions called through function pointers from cfi.c. I just hope people are not put off by the high frequency of changes which causes their patches to fail. I think its best to concentrate on one area at a time and finish it first before moving to another area. This reduces the chance two (or more) people are working on the same code. Nico Coesel > -----Oorspronkelijk bericht----- > Van: openocd-development-boun...@lists.berlios.de > [mailto:openocd-development-boun...@lists.berlios.de] Namens > Zach Welch > Verzonden: woensdag 22 april 2009 4:56 > Aan: Openocd-Dev > Onderwerp: [Openocd-development] my tech proposal > > Hi all, > > This message follows my sentiments about the human side of > OpenOCD with a more technically focused perspective. > > First off: if you had conflicts that prevent a clean 'svn > diff' patch, you should be able to copy your original > pre-merged files (the .mine > files) into a fresh working copy of the older revision (along > with changes to any other files that did merge okay) and > extract the clean patch therein. Let me know if this advice > is not as helpful as I think it should be; if all else fails, > send me your entire working copy and I will deal with the > mess that I caused. > > Anyway, here is my current list of outstanding tasks, where > '+' items have a current patch and '-' items do not. This is > not a milestone task list; I am leaving that as someone > else's responsibility. > > * FT2232 driver: > + integrate FTD2XX High-Speed Device Patch (Joern Kaipf + ZW) > +? remove non-A types (Uwe Hermann) (does this patch still apply?) > - fix segfault from long scan chains (observed by Dick Hollenbeck) > - fix non-recoverability of cable connect/reconnect > - cure buggy madness (others might try to break this into pieces) > > * J-Link driver (w/ yellow hardware) > - integrate Jeff and Duane's pending changes > - cure buggy madness (this is my own poorly qualified TODO item) > - test on known targets > > * MC1322x target support > - integrate and test support from Jeff and Duane > - get working with a known good interface (i.e. not today's jlink) > > * TAP changes: > - use tap_set_state everywhere to allow logging TAP state > transitions > - add new TAP state table provided by Jeff Williams > - update tap_get_tms_path API as suggested by Duane Ellis > - slow boat: add tap_get_tms_path2 and allow both for a while > - convert drivers that use old API over to the new one > - remove old tap_get_tms_path > - other changes work picking out of Jeff/Duane's patches > > * CFI: > - factor vendor-specific code into separate source files > - investigate adding new interface to those bits? > > * Architectural Upgrades > - Allow N:M:P mapping of servers, targets, and interfaces > > * ARM: > - better alignment with ARM technical documentation (Jeff W.) > > * Miscellaneous: > - continue to improve state and system debugging (Jeff W.) > - overhaul use of types to improve 32/64-bit portability > - factor drivers to improve re-use > > If I do not include something important to you, it was not > intentional; simply follow-up with a your items and I will > add them to the next version. I am not interested in keep > track of what goes in (the repo log does that), so I will > simply drop items when that happens for them. > > I hope that -- by maintaining this list and posting it here > -- everyone will take away the idea that I care about the > project's architecture. > I seriously considered writing a competing implementation, > because I _knew_ there would be this kind of resistance to change. > > I see the potential massive changes that would benefit the > system, such as the list item for OpenOCD to allow > heterogeneous configurations of servers, targets, and > interfaces (N:M:P). Admittedly, this was suggested by others > recently (though I can't find the exact thread at the > moment), but it is the kind of task that I might find entertaining. > I see other potential in the code, but I still have not been > able to get my head around the nature of everything needs to > be done. There a lot. > > If I could afford to play in this sandbox at this level of > intensity indefinitely, I could help make those visions real, > but -- even if that was fiscally and physically feasible -- > that process would take a lot of trust and courage on the > part of the community. Still, it doesn't matter who actually > makes those changes; they will be painful, but the metaphor > of surgery is apt. We must cut to cure. > > That will result in a slow-but-steady flow of incremental > patches, which would add up to a lot of churn. As I am but a > babe in the woods around here, I will not presume to know > what is best for this project, but I know a thing or two > about what it takes to produce software. If we want to reach > for big goals, pain will be all but unavoidable. > > I present this plan in the hope it can ratified by the > community to help us move forward on the same page. Reaching > a meaningful 1.0 will require commitment to making multitudes > of the sort of changes that I have started. Dealing with > merging and conflicts is a necessary evil of working with > open source; the only cure is to publish your patches first > and get them into the tree. I haven't had a conflict all week. ;) :) > > Cheers, > > Zach > _______________________________________________ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
