Duane Ellis wrote: > Michael Schwingen wrote: >> First, I think the target code should stay as small as possible, >> because there may be targets where very little RAM is available for >> the code. > > I disagree, I think we always have 4K of ram, here's why: > > Generally: > There are two classes of devices. > 1) Those with internal flash. 2) Those with external flash. > > Assertion: > During "flash programing", openocd controls the world and the chip. > And - there is "ram to be had some where" that openocd can use.
That depends. Getting DDR2 SDRAM controllers initialized can be a quite tedious task, so you may be stuck with what internal SRAM you have available. The IXP42x has 2k mini-IC available for code, other CPUs may have even smaller TCMs as the only space available during board bringup - I remember I had to use the slow flash write when working on a Feroceon CPU (with a BDI2000), because not enough RAM was available for the target-running flash code. Also, even if 4k is enough for now, when we start adding more flash routines to the code, at some point, it *will* get too big, so we will have to split it up anyway. A design that can not handle targets with small amounts of memory, although the code would fit, is bad IMHO. > Assertion: > The target here is *NOT* embedded "8051" or 'tiny pic' or 'tiny avr' > type micro controllers > Those have their own flash programing solutions - and debug tools. > We are not trying to solve those problems here with openocd. > > Assertion: > OpenOCD targets are a 16/32bit chips with JTAG and a recent vintage. > (Yea, I know there are 6502 ports for GCC...) > > Assertion: > The target uses GCC and/or GDB. > > Assertion: > Anything matching the above - is either > (1) a micro controller with internal flash (and ram) or > (2) has external memory that can be configured some how. > (ie: maybe to config ram, one must write a sequence of 'mww' commands) There are small variants (1) that are definitely microcontrollers, but do have an external bus where additional flash may be attached. And especially on big CPUs, setting up RAM may be quite a bit more work than a simple sequence of mww commands. > If they are true - then - I believe we can easily claim "4K" is reasonable. > With 4K - the little "blob" of code can be quite powerful. > Even if we must limit it to 2K - there are some simplistic methods one > can accomplish. I do not see the advantage of having all the flash code in one big blob. After all, you will never need them all at the same time - when you are programming an intel flash, the code for AMD, SPI etc. is useless and takes up space. When you have two flashs that require different code, swapping the programming code when switching between the two is fast and painless (and you can keep both resident in the target *if* you have enough RAM). Putting it all together in one blob with a dispatcher provides no added benefit IMHO - openocd knows what target code there is, and can jump directly to the required function without a dispatcher on the target deciding what to do. cu Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
