Hello Simon :-) 2012/3/13 simonqian.openocd <simonqian.open...@gmail.com>: > I have recently read libswd code and want to somewhat push the SWD progress.
Cool :-) > First modification should be to arm_adi_v5.c and/or adi_v5_jtag/swd.c, so > that arm_adi_v5.c could be transport independent. First, we should not modify anything, but discuss what is the status of the work, what and how we should change anything, if necessary. You should not modify a code I am currently working on and starts to work, see my comments below :-) The TRANSPORT layer is here to make OpenOCD modular and transport independent, just as interface independent, etc. > I found both libswd and my SWD patch modify 2 main functions in > arm_adi_v5.c, which are ahbap_debugport_init and mem_ap_read_buf_u32. LibSWD im far more complex than that - it only modify OpenOCD code where absolutely necessary. This is also why it takes so long to make it work, because library needs to fix design errors of the application. The debugport_init was changes because sticky flags handling is different for jtag and swd. We should create additional transport independent function set to check and remove error conditions, or simply check what is the transport and apply proper operation in place.. The first option could become additional transport routine. > ahbap_debugport_init should obviously be modified to initialize SWD if SWD > transport is sellected. ..or we can create transport independent sticky flags handling, because rest of the initialization is the same, see above :-) > And mem_ap_read_buf_u32 should not call adi_jtag_dp_scan, or implement > mem_ap_read_buf_u32_jtag and mem_ap_read_buf_u32_swd. mem_ap_read_buf_u32 has a dirty hack that hardcodes use of jtag functions. This is why I simply created a wrapper to call existing funtion if jtag is used (backward compatibility) and/or call new function that use swd transport. The problem with acessing the MEM-AP is somehow more complex, especially when sticky error handling is active. The below is what I found working last Sunday, but this is so different from the ARM documentation: 1. We need to set the MEM-AP configuration (TAR, ...) 2. We acess DRW to read the memory content, but this only triggers read operation, so we get ACK=WAIT. 3. In perfect situation we should poll for READOK in CTRL/STAT and when its set we should read the RDBUFF with memory contents. But the reality is different. 4. Because taget returned ACK=WAIT further operations return FAULT. We need to cleat sticky error flags. 4. We read the CTRL/STAT error flags to know which needs to be cleared. 5. We write to the ABORT register to clear the flags. This however according to ARM ADIv5.1 (errata section) 2.10 aborts the MEM-AP operation and since then RDBUFF value is unpredicted! How the hell was that designed if ABORT write is mandatory after ACK!=OK ?! 6. We retry DRW read operation, at this point we should get ACK=OK because TAR did not change, but we get the result of last memory read. 7. We need to read RDBUFF in order to get result of our read call ! Note few important details: 1. This is different than abiguous specification. 2. OpenOCD does not have retry mechanism of any kind, so I had to implement it in LibSWD. 3. OpenOCD can queue more read write operations and then flush the queue. Again it does not check where was the error, simply crashes if execution failed, so I had to add error handling as everything went smooth in LibSWD (imagine working with such thing at queue level). 4. Enqueueing read operations will dramatically increase efficiency, but it also complicates code that does not use double pointers, also the error handling is far more complex. 5. We dont know what will happen if TAR autoincrement is active, this solution might not work... This is what I am working at the moment. The work is somehow slow because noone want to support it recently with their investment and/or resources, everyone just want the results for free, and I need to work. Recently the work was intensified somehow with Akos we are pushing forward, the retry mechanism seems to be working at last, I need to clean up the code and push it to the repo, I was planning to do this yesterday but I had to conduct some lessons at the university, also have lots of work at work... will do this asap :-) > 2 solutions: > 1. In my SWD patch, I add queue_dp_scan to dap->op, and implement > dap_queue_dp_scan to call dap->op->queue_dp_scan instead of JTAG ones. > And queue_dp_scan is implemented in both jtag_dp_ops and swd_dp_ops. How would dp_scan work? > 2. In libswd code, 2 functions are implemented for mem_ap_read_buf_u32, > which are mem_ap_read_buf_u32_jtag and mem_ap_read_buf_u32_swd. > And they are called in mem_ap_read_buf_u32 according to the transport > sellected. The mem_ap_read_buf_u32 should use transport independent routine provided by transport layer and we should get rid of the jtag-specific dirty hack. This is not libswd change itself but fix in the OpenOCD :-) > So the result is simple, choose one of the 2 methods above. > Both are OK for me if we can make progress. > And I can prepare the patch if any one want to try. Please just do not interfere with my current work, we need well planned work not another wave of dirty patches - what you proposed is obvious but the problem is somewhere else when you look at details :-) You better tell me Simon how did you manage the mem-ap read retry on ack==wait, this would help me a lot to clarify that mechanism and finish the job faster :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
