Duane Ellis wrote: > The idea is this: > Let us assume there is a 4K block (working space) of ram some where. > The code could be 2K, set aside 1K for stack (yes 1K) > And 1K for a download buffer - could be bigger.. > Maybe we work with 4K and 4K... > > The entry point would be fixed - always at Buffer+0 > Set the program counter there, nothing else needs set. > > Then, set a SW breakpoint at - a fixed location. > Example: Buffer + 0x10 > This would leave a few bytes @ the start for startup code > And might be easier for different chips (ie: non-arm chips). > > The target code *RUNS*, sets up the stack and then enters > some type of "for-ever" loop, that looks like this: > *AND* is 100% written in *C* code - not assembler. > OK so far. However, I would like to keep the current small objects like those used in the CFI flash code, and download them on demand, instead of one big blob that handles everything, because:
- Buffer space may be severely limited on some CPUs, and by only loading the one algorithm needed for a task, we make best use of that RAM, freeing the rest for buffer. If we pack all code into one target binary blob, it may expand to a size where not everything fits on some targets. - Easier to maintain. We have target code for one single task (eg. flash Intel-style NOR flash roms - just like the current CFI code does), with a defined interface (input and output values at defined places in the buffer), plus the matching host-side code inside OpenOCD that runs that code. I do think that the target algorithm code should be written in C, with a small bit of assembler startup (just as much as is needed to setup stack etc. to run C code). The startup code is CPU/architecture dependant and needs to be written once for each supported CPU family. The algorithm code is pure C and can be used without modifications on any target CPU, regardless of the instruction set. > Why do I suggest C? And the above method... > Because it would work on *ALL* targets! > One only needs to *compile* a small C program. > And little helpers would be very fast. > Ack. The current code that is embedded in the CFI flash code is difficult to read and even more difficult to modify, and is platform-specific. In order to make this work, we need some way to load and relocate the object code to an address that is not known at compile/link time (or a compiler that generates position-independent code for all plattforms). I am not sure if we can simply use ELF files for the target code, and use the existing ELF loader, with the addition of relocation if needed? The ELF files could be shipped with OpenOCD (because you need cross-compilers for all architectures to re-generate them), and the code in OpenOCD would simply request to load "cfi_intel" to a target buffer, which the general code then turns into a load of ".../openocd/lib/arm/xscale/cfi_intel.elf", handling buffer management, setup and relocation. cu Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
