Re: [Openocd-development] my tech proposal
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
Re: [Openocd-development] my tech proposal
On Wed, Apr 22, 2009 at 5:33 PM, Zach Welch z...@superlucidity.net wrote: These will appear in the next revision of my list. I have been thinking about what I want my next hobby board to be, and the Cortex A8 has been one possible choice. [[I am now hoping a board vendor reads this, recognizes their opportunity, and drops one in the mail to me. ;) ]] How much of the Coldfire support would need to be reverse-engineered? With specifications and hardware, half of the battle will have already been won, but the lack of an open source solution makes me guess unencumbered references are unavailable. Posting links to references would help plant seed for others to pick this up and run with it. Not so sure if this one is good enough. http://bdm.sourceforge.net/ -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] my tech proposal
On Wed, 2009-04-22 at 17:43 +0800, Xiaofan Chen wrote: On Wed, Apr 22, 2009 at 5:33 PM, Zach Welch z...@superlucidity.net wrote: These will appear in the next revision of my list. I have been thinking about what I want my next hobby board to be, and the Cortex A8 has been one possible choice. [[I am now hoping a board vendor reads this, recognizes their opportunity, and drops one in the mail to me. ;) ]] How much of the Coldfire support would need to be reverse-engineered? With specifications and hardware, half of the battle will have already been won, but the lack of an open source solution makes me guess unencumbered references are unavailable. Posting links to references would help plant seed for others to pick this up and run with it. Not so sure if this one is good enough. http://bdm.sourceforge.net/ Me neither, but it looks like anyone wanting to give this a whack would be wise to check in with that community and look over their code. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] my tech proposal
On Wed, 2009-04-22 at 08:04 +0200, Øyvind Harboe wrote: Great posting! Can I suggest that you create this as a patch against svn so we can match up the todo.txt list against an actual version of the OpenOCD svn history? Can't I simply claim that it's on The List? ;) I definitely agree that I should be providing the revision number, but I have evolved the idea that TODO files inside repositories get treated the same way as other files do: people fear change. They become monumental testimonies to the good intentions of the ambitious. I know; I've written my fair share. Instead, I am hoping that it can serve more to guide contributors into regular project management discussions. Patches would hide all but the latest activity, and I want people to be reminded and energized by the web of goals that lurk behind the daily grind. The List will give a complete picture of the activities reported and pending; it only needs be reposted after sufficient changes have taken place. Ideally, folks will start to volunteer to cherry-pick tasks off of it. I think we will see more of that if it gets posted regularly; it should clearly be a fresh artifact and contain items that we really intend to carry forward. Since I am volunteering to take on this challenge of trying to herd cats in this manner, I hope the community is willing to embrace this idea for a time (or give me a better alternative). Project management can be tricky. I am still trying to get it right, and -- though I may screw up often -- I hope my effort is appreciated. In that vein, thanks to you and all others that have been supportive. I live, I learn, and I try to improve. W.r.t. churn, I think it would be helpful, as you do, to try to get a lot of those warning fixes out of the way so that at least the overall codebase is a bit more stable and then hopefully the churn is localized to a set of files at any one time. I think that we have passed the warning fixes stage at this point, with -Werror surviving intact. I might be wrong and some corner cases remain to be reported, but I believe the community has chimed in on the problems for all of the major ones. Fixes are in tree for all of them, as far as I am aware. [[New bugs are another thing, as the recent post from Andy Chenee shows. Sorry about that one.]] At this point, the use of -Werror will keep us from having to go through that particular flavor of pain again, so things should only get better. * Architectural Upgrades - Allow N:M:P mapping of servers, targets, and interfaces - About CFI: I'd like to see if the ecosflash driver could not be used to take a CFI driver from e.g. eCos and use that in OpenOCD. The current OpenOCD CFI driver is fine, such as it is, but e.g. eCos CFI drivers are getting a *LOT* of testing from a much bigger community. Added, though you will need to check that I interpreted you correctly. - New targets? Any that you have in mind? Coldfire and Cortex are on thanks to Nico. MC1322x from Jeff. I have added an insert your target here item. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] my tech proposal
- New targets? Any that you have in mind? Coldfire and Cortex are on thanks to Nico. MC1322x from Jeff. I have added an insert your target here item. arm11 has a lot of support already, but could need more love... -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] my tech proposal
On Wed, 2009-04-22 at 12:59 +0200, Nico Coesel wrote: [snip] I looked at the BDM project Xiaofan posted. It seems like a good starting point. It also has routines for external flash. Maybe its worth to look into it to get some fresh ideas on the cfi implementation as well. I used to have a Coldfire board but we returned it because of the lack of proper hardware programming tools (Codesourcery has a complete GCC kit for Coldfire). If someone has Coldfire hardware, I bet the community would be willing to work with them to get it going, but it would be a lot of work. However, that gets me wondering of opportunities to wrangle up some kind of sponsorship for the bootstrapping phase (e.g. Google Summer of Code). Food for communal thought. [snip] Okay, I've attached a patch to cfi.c to this e-mail. Note this is a work in progress. It works for my situation though (Spansion flash). The major change I made is adding cfi_spansion_wait_write and calling keep_alive to avoid the usleep when calling alive_sleep(1). Sleeping the CPU during erase is fine, but not during programming. This still needs masking (bus width) and perhaps checking endianess. Thanks! Since I do not have CFI hardware on hand, I must leave it up to others to review and either commit or provide feedback, but I will keep this topic on my radar. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] my tech proposal
On Wed, 2009-04-22 at 13:00 +0200, Øyvind Harboe wrote: - New targets? Any that you have in mind? Coldfire and Cortex are on thanks to Nico. MC1322x from Jeff. I have added an insert your target here item. arm11 has a lot of support already, but could need more love... Can you elaborate need more love into bullet points? :) If not, it might help to CC those who can in the hope to solicit further details for the community to consider. I suppose that goes for anyone else that you know has things they want done, as having lots of easy tasks is a great path for new developers to get started with the code. While I was able to make my own list, others are not as foolhardy. To help frame further discussion, I will repost The List shortly. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] my tech proposal
On Tue, Apr 21, 2009 at 07:55:46PM -0700, Zach Welch wrote: * MC1322x target support - integrate and test support from Jeff and Duane - get working with a known good interface (i.e. not today's jlink) I plan to be working on this (hi everyone. I haven't posted yet, but have been listening). I've been working on supporting the mc1322x with open tools for about a month now. It sounds like the problems are coming from the following sources: - Jlink - ARM/THUMB switches - and the mc1322x Does that sound about right? I'm waiting for some FTDI based hardware (since today's jlink is out) so I won't be able to make any progress until then (or until tomorrow's jlink arrives). I'm going to put my openocd work up on mc1322x.devl.org (along with all my other stuff). I plan to use jeff's patches as a starting point. Is there anyone else on this list (besides jeffw) working with the mc1322x? -Mar. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] my tech proposal
On Apr 22, 2009, at 10:24 AM, Mariano Alvira wrote: On Wed, Apr 22, 2009 at 10:19:06AM -0700, Rick Altherr wrote: Can we just open a branch in the main OpenOCD repo instead? Having separate repos just make it more difficult to track things down and do merges. I think git makes this easy. This way you can do your thing and I can do mine. When I have something valuable to you guys I'll submit a patch. -Mar. git makes the merging easier, but there is still the people problem of finding the development branch to try it out. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
