Zach, > CC: Openocd-Dev > Onderwerp: Re: [Openocd-development] my tech proposal > > On Wed, 2009-04-22 at 10:35 +0200, Nico Coesel wrote: > > 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. > > 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.
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). > > 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. > > Post code to the list, but we are on the same wavelength. Completely. 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. Nico Coesel
cfi.c.speedup.patch
Description: cfi.c.speedup.patch
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
