On Wed, Mar 14, 2012 at 1:23 PM, simonqian.openocd <simonqian.open...@gmail.com> wrote: >> I would prefer to create dedicated reset function in arm_adi_v5 if >> possible to use existing dp/ap read/write functions, to keep dap_ops >> interface functions as compact as possible, but if thats not possible the >> additional member of dap_ops seems unavoidable :-) > > The reset function will control srst in SWD mode. The existing dp/ap > read/write functions will not be called.
Why do we need to create sRST in DAP? sRST is an Interface signal, it should be handled by a interface as it is logically bounded to this part of the system (ft2232 has even reset layouts defined), not by Target or Transport. Target should have a function to reset DAP (this can be done with DAP RESET sequence for SWD and some TMS+TCK sequence for JTAG) using Transport function set, and/or System reset using interface instal. This function should be general enough to be easily implemented on different hardware. I have prepared general/generic signal handling for an interface (see src/interface) - it adds interface_signal and bitbang that can work with these signals. I think first we need to clarify the logical boundaries of the layers, then split the code fragments, it can be something like this: 0. OpenOCD Context (oocdctx) - will hold all information on the openocd thread, join information flow between layers below. 1. Interface - provides communication between logical queue/bitstream and physical signaling to the target. 2. Board - is what we connect the cable at the target device. Here could be place for sRST etc :-) 3. Transport - is a bridge between target commands and interface, it translates read/write operation into bit sequences on the interface. 4. Target - is the standard and minimal function set that gives us access to the target chip internal peripherals (DAP, MEM-AP, ICE, ...). 5.1. Memory - allows to access memory contents (nor, nand, cfi) on target system using Target function set. 5.2. CPU - allows access to the selected cpu registers (also allows to clearly implement smp in a clear way) using Target function set. 5.3. OS - allows to interact with the operating system on the target, listing processes, etc, using standard Target function set. 5.4. IO - allows to access I/O ports on selected device using standard Target function set. ... It is very important for us to define and work on layers 0..4 at the moment because it does not exist or some parts are still missing (i.e. such simple thing as reset for transport). The TARGET seems to be most important as it is a base for all other upper layers. Layers should only use layers below for clear and unambiguous information/program flow... Placing generic reset routine in Target seems reasonable, but it might be even better to create and place it in BOARD layer, as there might be multiple Targets onboard (I have seen such posts in the past) and so we would then have clear distinction between target and board. The implementation for that reset will be (is already src/interface) placed in Interface layer. Board layer could also have additional features such as power switch etc for full remote automation which is usually desired:-) > You can save your time and prepare for libswd. > What I need is the common points of view about how it should be implemented. I think making current code modular and divided into layers as described above would be best thing to start because then we would have clean and elegant form to work on. Adding new features that way should be a pleasant task :-) But this is time consuming task, I have tried that last year and I gave up after month or two on behalf of the swd work itself, but I was not that familiar with the code as right now. Anyway, we can simply make things work at the moment as best as we could, then fix and further develop the code, I like this approach :-) > Below is the speed when programming flash of stm32 using versaloon. > For STM32 chips, it gets about 8KB/s - 12KB/s under SWD mode in OpenOCD. > In vsprog, it gets about 35KB/s because vsprog uses a double buffer > operation, which means data can be transmitted to ram of target stm32 via > SWD while stm32 is doing the flash programming. This is nice :-) I think I am using single bit per transfer on USB and this is why it is sooo slow, I will try to pack data into bytes and send bytes instead, that should give at least 5x better performance... How does double buffer work exactly - is it a feature of ARM Cortex MEM-AP? Or you mean to transfer command queue into vsprog/versaloon ram and then execute it for better performance? Could that mechanism/speedup be implemented in OpenOCD as well? Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
