UrJTAG txt update: how to use initbus

git-svn-id: https://urjtag.svn.sourceforge.net/svnroot/urjtag/trunk@1047 b68d4a1b-bc3d-0410-92ed-d4ac073336b7

jtag/ChangeLog

@@ -1,3 +1,7 @@
+2008-02-18  Kolja Waschk <kawk>
+
+   * doc/UrJTAG.txt: How to use initbus (and ejtag/prototype bus driver).
+
 2008-02-17  Arnim Laeuger  <arniml@users.sourceforge.net>
 
    * configure.ac: check for pre-generated src/svf/svf_flex.c

jtag/doc/UrJTAG.txt

@@ -682,6 +682,57 @@ particular core inside the chip (e.g.  ARM7TDMI), but doesn't tell about the
 actual manufacturer of the chip. In such case, the data for the part has to be
 included manually. See also the documentation for the "include" command.
 
+===== initbus =====
+
+Selects and initializes a bus of the currently selected part. This is required
+in order to access chips that aren't connected in the JTAG chain, but indirectly
+accessible through other chips (e.g. CPU or programmable logic). 
+
+Type "help initbus" to get a list of supported bus types. Most drivers work
+"via BSR", i.e. they directly access the pins of the device. Because it isn't
+possible to efficiently address only particular pins but only all at once, and
+data for all pins has to be transferred through JTAG for every single change,
+this method isn't the fastest, but usually easiest to implement and, well,
+sometimes it counts whether it works at all..
+
+If you do not find a bus driver for your specific hardware, you might be lucky
+enough to have EJTAG in your target (most MIPS-based CPUs do) and should try
+the "ejtag" bus driver. In contrast to the method "via BSR", it uploads some
+instructions to the CPU and triggers their execution to access the bus, and
+should work with almost any EJTAG-capable chip (Note: JTAG isn't EJTAG):
+
+  jtag> initbus ejtag
+
+There's another option to support new chips "via BSR", the "prototype" bus
+driver, which can be adapted to support your part with command parameters.  The
+only prerequisite for using this driver is knowledge of the names of the
+signals that represent address bus, data bus, and enable signals, and that
+address and data lines are numbered in order.
+
+For example, assume the signals are named in the BSDL description as follows:
+
+ * Data bus: D0, D1, ... D31
+ * Address bus: ADDR0, ADDR1, ... ADDR22
+ * Output Enable: nOE
+ * Write Enable: nWE 
+ * Chip Select: nRCS0
+
+The enable signals seem to be active low (indicated by the leading "n" in their
+names). Further we assume the interesting connected part, some flash chip, is
+only 16 bits wide even though the data bus width is 32 bits.  With this
+information, you could use the following command (all on a single line!) to
+access the bus:
+
+  initbus prototype amsb=ADDR22 alsb=ADDR0 dmsb=D15 dlsb=D0
+            ncs=nRCS0 nwe=nWE noe=nOE amode=x16
+
+The "prototype" bus driver yet cannot deal with systems where address and data bus
+are multiplexed on the same pins. 
+
+Some chips don't allow direct access to their pins via JTAG (using the method
+"via BSR") at all. For these, writing a new bus driver that utilizes a debug
+module to upload specific code to access the bus is inevitable.
+
 ==== Highlevel commands ====
 
 ===== svf =====