On Nov 30, 2008, at 9:59 PM, Duane Ellis wrote:
duane> What is the required work area size? rick> None. The flash methods ....Actually the flash methods do need space - otherwise they will not work.
That isn't true for at least the Stellaris flash code. It will fall back to hitting the flash control registers for each word individually. I don't know the other drivers very well, but they seemed to do something similar.
Thank you for pointing out the flash - I had forgotten about that. There are two sides to the problem.(A) flash programing - I had forgotten. Happens, but not as frequently.(B) General GDB downloading: Happens all the time. I dug around a little... and this is what I found. -Duane. DCC download requires 24 bytes. Poking around the flash code I see this: ie: LPC2000 I see something 172 bytes needed I see stuff in the CFI Intel flash code talking about 1K bytes.All FLASH code has the same copy/paste loop that wants something more then 256 bytes
It all depends. Most of the flash algorithms (the part that runs on the target) take a word count as part of the initial register state. The actual algorithm depends on the flash controller being used so the base size of the code will also change. They also allocate a separate area for the data block to be written. Those are variable size and the size is part of the initial register state for the algorithm.
================================
Based on my read of the code:
I think this would be "good manual/documentation policy"
(A) From a *manual* point of view.
Flash programing requires at least :
1K ram for micro-controllers (internal flash)
2K ram for any external flash.
For *large* system on a chip solutions - 2K is enough
However we recommend 4K on systems with SDRAM.
For microcontrollers, 1K is plenty, but at least for some flash drivers, none is necessary. We should be more explicit than just saying "1K minimum." What happens if no working area is available? Do they fallback to a slow mechanism or does it return a failure?
(B) From a *manual* point of view.. We tell users: If at all possible - dedicate a N-Byte region for the DCC.Today N = 24 bytes, but think future. Should the manual say 64 bytes - or 128 bytes?And use the extra bytes for data abort capturing (if needed)
What happens if no work area is defined in the config? It should fall back to something reasonable, albeit slow.
(C) FUTURE: Maybe we even create a "-dcc-work-area" target option? It would always be backed up and restored .. And - it needs to be smart about GDB loading over the top of it. Maybe we create a "-flash-work-area" target option?Today - existing OpenOCD code treats "work area as work area" generically.
I see no reason to make these separate. On small devices, RAM is already at a premium. Making the two working areas separate means _more_ space has to be dedicated to OpenOCD. There doesn't seem to be any advantage other than having the DCC area always backup. That isn't even really necessary. Backing up the area is slow and if the target app has been designed such that an unused area of RAM is available, we shouldn't waste time doing a backup. Only the config file writer know the right thing to do and we should make it simple for them.
(D) On chips like ARM 9 - that have Vector Catch. Vector Catch should be enabled during this period. And "restored to previous state" when done. Perhaps this should be on any time "run algorithm" is used. (E) Not sure about Vector Catch on Arm7. Not familiar enough with arm11 and cortex variants. (F) Some places for work could be: Improve the flash algorithms to "ping-pong"buffers ie: Instead of polling the flash for completion Start downloading the next sector.
That would require 2 buffers in the working area so the individual algorithm runs would be on half-sized blocks. That _might_ be suboptimal for some flash controllers unless the working area is doubled.
======= **END** =======
-- Rick Altherr [EMAIL PROTECTED]"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
