X-Git-Url: https://review.openocd.org/gitweb?p=openocd.git;a=blobdiff_plain;f=TODO;h=283ed5f3a95e69fff4f59464967cd63460b992ce;hp=2b2bb40545e4a87485099631e7b6ced9ac4f3e79;hb=016e7ebbfa034926c980b4b33b964f6078541690;hpb=d3f0919233de208f2fa253397eb01c7d1329f1ab diff --git a/TODO b/TODO index 2b2bb40545..283ed5f3a9 100644 --- a/TODO +++ b/TODO @@ -1,2 +1,300 @@ -This document is not in use. See mailing list. +// This file is part of the Doyxgen Developer Manual +/** @page tasks Pending and Open Tasks +This page lists pending and open tasks being considered or worked upon +by the OpenOCD community. + +@section thelist The List + +Most items are open for the taking, but please post to the mailing list +before spending much time working on anything lists here. The community +may have evolved an idea since it was added here. + +Feel free to send patches to add or clarify items on this list, too. + +@section thelisttcl TCL + +This section provides possible things to improve with OpenOCD's TCL support. + +- Fix problem with incorrect line numbers reported for a syntax + error in a reset init event. + +- organize the TCL configurations: + - provide more directory structure for boards/targets? + - factor configurations into layers (encapsulation and re-use) + +- Isolate all TCL command support: + - Pure C CLI implementations using --disable-builtin-tcl. + - Allow developers to build new dongles using OpenOCD's JTAG core. + - At first, provide only low-level JTAG support; target layer and + above rely heavily on scripting event mechanisms. + - Allow full TCL support? add --with-tcl=/path/to/installed/tcl + - Move TCL support out of foo.[ch] and into foo_tcl.[ch] (other ideas?) + - See src/jtag/core.c and src/jtag/tcl.c for an example. + - allow some of these TCL command modules to be dynamically loadable? + +@section thelistjtag JTAG + +This section list issues that need to be resolved in the JTAG layer. + +@subsection thelistjtagcore JTAG Core + +The following tasks have been suggested for cleaning up the JTAG layer: + +- use tap_set_state everywhere to allow logging TAP state transitions +- rename other tap_states to use standard JTAG names (suggested by ML) +- Encapsulate cmd_queue_cur_state and related varaible handling. +- add slick 32 bit versions of jtag_add_xxx_scan() that avoids +buf_set_u32() calls and other evidence of poor impedance match between +API and calling code. New API should cut down # of lines in calling +code by 100's and make things clearer. Also potentially be supported +directly in minidriver API for better embedded host performance. + +The following tasks have been suggested for adding new core JTAG support: + +- autodetect devices present on the scan chain + - implement 'discover_taps' command +- SPI/UART emulation: + - (ab)use bit-banging JTAG interfaces to emulate SPI/UART + - allow SPI to program flash, MCUs, etc. + +@subsection thelistjtaginterfaces JTAG Interfaces + +The following tasks have been suggeted for improving OpenOCD's JTAG +interface support: + +- rework USB communication to be more robust. Two possible options are: + -# use libusb-1.0.1 with libusb-compat-0.1.1 (non-blocking I/O wrapper) + -# rewrite implementation to use non-blocking I/O +- J-Link driver: + - fix to work with long scan chains, such as R.Doss's svf test. +- FT2232 (libftdi): + - make performance comparable to alternatives + - make usability comparable to alternatives + +The following tasks have been suggested for adding new JTAG interfaces: + +- TCP driver: allow client/server for remote JTAG interface control. + +@section thelistswd Serial Wire Debug + +- implement Serial Wire Debug interface + +@section thelistbs Boundary Scan Support + +- add STAPL support? +- add BSDL support? + +A few possible options for the above: + -# Fake a TCL equivalent? + -# Integrate an existing library? + -# Write a new C implementation a la Jim? + +Once the above are completed: +- add support for programming flash using boundary scan techniques +- add integration with a modified gerber view program: + - provide means to view the PCB and select pins and traces + - allow use-cases such as the following: + - @b Stimulus + -# Double-click on a pin (or trace) with the mouse. + - @b Effects + -# The trace starts blinking, and + -# OpenOCD toggles the pin(s) 0/1. + +@section thelisttargets Target Support + +- general layer cleanup: @par + https://lists.berlios.de/pipermail/openocd-development/2009-May/006590.html +- regression: xscale does not place debug_handler.bin into the right spot. workaround: + use -s option on command line to place xscale/debug_handler.bin in search path @par + https://lists.berlios.de/pipermail/openocd-development/2009-July/009338.html +- bug: either USBprog is broken with new tms sequence or there is a general + problem with XScale and the new tms sequence. Workaround: use "tms_sequence long" + @par + https://lists.berlios.de/pipermail/openocd-development/2009-July/009426.html +- regression: "reset halt" between 729(works) and 788(fails): @par +https://lists.berlios.de/pipermail/openocd-development/2009-July/009206.html +- ARM7/9: + - add reset option to allow programming embedded ice while srst is asserted. + Some CPUs will gate the JTAG clock when srst is asserted and in this case, + it is necessary to program embedded ice and then assert srst afterwards. +- ARM923EJS: + - reset run/halt/step is not robust; needs testing to map out problems. +- ARM11 improvements (MB?) + - fix single stepping (reported by ØH). Need to automatically + use hardware stepping if available. + - hunt down and add timeouts to all infinite loops, e.g. arm11_run_instr_no_data would + lock up in infinite loop if e.g. an "mdh" command tries to read memory from invalid memory location. + Try mdh 0x40000000 on i.MX31 PDK + - mdb can return garbage data if read byte operation fails for + a memory region(16 & 32 byte access modes may be supported). Is this + a bug in the .MX31 PDK init script? Try on i.MX31 PDK: + mdw 0xb80005f0 0x8, mdh 0xb80005f0 0x10, mdb 0xb80005f0 0x20. mdb returns + garabage. + - implement missing functionality (grep FNC_INFO_NOTIMPLEMENTED ...) + - thumb support is missing: ISTR ARMv6 requires Thumb. + ARM1156 has Thumb2; ARM1136 doesn't. +- Cortex A8 support (ML) + - add target implementation (ML) +- Generic ARM run_algorithm() interface + - tagged struct wrapping ARM instructions and metadata + - not revision-specific (current: ARMv4+ARMv5 -or- ARMv6 -or- ARMv7) + - usable with at least arm_nandwrite() and generic CFI drivers +- MC1322x support (JW/DE?) + - integrate and test support from JW (and DE?) + - get working with a known good interface (i.e. not today's jlink) +- AT91SAM92xx: + - improvements for unknown-board-atmel-at91sam9260.cfg (RD) +- STR9x: (ZW) + - improvements to str912.cfg to be more general purpose +- AVR: (SQ) + - independently verify implementation + - incrementally improve working prototype in trunk. (SQ) + - work out how to debug this target + - AVR debugging protocol. +- FPGA: + - Altera Nios Soft-CPU support +- Coldfire (suggested by NC) + - can we draw from the BDM project? @par + http://bdm.sourceforge.net/ + + or the OSBDM package @par + http://forums.freescale.com/freescale/board/message?board.id=OSBDM08&thread.id=422 + +@section thelistsvf SVF/XSVF + +- develop SVF unit tests +- develop XSVF unit tests + +@section thelistflash Flash Support + +- finish documentation for the following flash drivers: + - avr + - ecosflash + - pic32mx + - ocl + - str9xpec + +@subsection thelistflashcfi CFI + +- finish implementing bus width/chip width handling (suggested by NC) +- factor vendor-specific code into separate source files + - add new callback interface for vendor-specific code +- investigate/implement "thin wrapper" to use eCos CFI drivers (ØH) + +@section thelistdebug Debugger Support + +- breakpoints can get lost in some circumstances: @par + https://lists.berlios.de/pipermail/openocd-development/2009-June/008853.html +- integrate Keil AGDI interface to OpenOCD? (submitted by Dario Vecchio) + +@section thelisttesting Testing Suite + +This section includes several related groups of ideas: +- @ref thelistunittests +- @ref thelistsmoketests +- @ref thelisttestreports +- @ref thelisttestgenerichw + +@subsection thelistunittests Unit Tests + +- add testing skeleton to provide frameworks for adding tests +- implement server unit tests +- implement JTAG core unit tests +- implement JTAG interface unit tests +- implement flash unit tests +- implement target unit tests + +@subsection thelistsmoketests Smoke Test Tools + +-# extend 'make check' with a smoketest app + - checks for OOCD_TEST_CONFIG, etc. in environment (or config file) + - if properly set, runs the smoke test with specified parameters + - openocd -f ${OOCD_TEST_CONFIG} + - implies a modular test suite (see below) + - should be able to run some minimal tests with dummy interface: + - compare results of baseline sanity checks with expected results + +-# builds a more complete test suite: + - existing testing/examples/ look like a great start + - all targets should be tested fully and for all capabilities + - we do NOT want a "lowest common denominator" test suite + - ... but can we start with one to get going? + - probably requires one test configuration file per board/target + - modularization can occur here, just like with targets/boards/chips + - coverage can increase over time, building up bundles of tests + +-# add new 'smoketest' Makefile target: + - calls 'make check' (and the smoketest app) + - gather inputs and output into a report file + +@subsection thelisttestreports Test Feedback Tools + +These ideas were first introduced here: @par + https://lists.berlios.de/pipermail/openocd-development/2009-May/006358.html + +- provide report submission scripts for e-mail and web forms +- add new Makefile targets to post the report: + - 'checkreportsend' -- send to list via e-mail (via sendmail) + - 'checkreportpost' -- send web form (via curl or other script) + +@subsection thelisttestgenerichw Generic Hardware Tester + +- implement VHDL to use for FPGA-based JTAG TAP testing device +- develop test suite that utilizes this testing device + +@section thelistautotools Autotools Build System + +- make entire configure process require less user consideration: + - automatically detect the features that are available, unless + options were specifically provided to configure + - provide a report of the drivers that will be build at the end of + running configure, so the users can verify which driverswill be + built during 'make' (and their options) . +- eliminate sources of confusion in @c bootstrap script: + -# Make @c bootstrap call 'configure --enable-maintainer-mode \'? + -# Add @c buildstrap script to assist with boostrap and configure steps. +- automatically build tool-chains required for cross-compiling + - produce mingw32, arm-elf, others using in-tree scripts + - build all required target code from sources +- make JTAG and USB debug output a run-time configuration option + +@section thelistarchitecture Architectural Tasks + +The following architectural tasks need to be accomplished and should be +fairly easy to complete: + +- clean-up code to match style guides +- factor code to eliminate duplicated functionality +- rewrite code that uses casts to access 16-bit and larger types + from unaligned memory addresses +- libopenocd support: @par + https://lists.berlios.de/pipermail/openocd-development/2009-May/006405.html +- review and clean up interface/target/flash APIs + +The following strategic tasks will require ambition, knowledge, and time +to complete: + +- overhaul use of types to improve 32/64-bit portability + - types for both host and target word sizes? + - can we use GDB's CORE_TYPE support? +- Allow N:M:P mapping of servers, targets, and interfaces +- loadable module support for interface/target/flash drivers and commands + - support both static and dynamic modules. + - should probably use libltdl for dynamic library handing. + +@section thelistadmin Documentation Tasks + +- Develop milestone and release guidelines, processes, and scripts. +- Develop "style" guidelines (and scripts) for maintainers: + - reviewing patches + - committing to Subversion +- Review The Guide for OpenOCD Users for documentation errors or omissions +- Update The Manual for OpenOCD Developerrs: + - Add documentation describing the architecture of each module + - Provide more Technical Primers to bootstrap contributor knowledge + +*/ +/** @file +This file contains the @ref thelist page. +*/