From 3ad72fc9f9792b97ecf3da83bdd5d1c33b89da26 Mon Sep 17 00:00:00 2001 From: Kolja Waschk Date: Mon, 18 Feb 2008 08:03:43 +0000 Subject: [PATCH] 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 | 4 ++++ jtag/doc/UrJTAG.txt | 51 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 55 insertions(+) diff --git a/jtag/ChangeLog b/jtag/ChangeLog index 89321ee4..7f8b164b 100644 --- a/jtag/ChangeLog +++ b/jtag/ChangeLog @@ -1,3 +1,7 @@ +2008-02-18 Kolja Waschk + + * doc/UrJTAG.txt: How to use initbus (and ejtag/prototype bus driver). + 2008-02-17 Arnim Laeuger * configure.ac: check for pre-generated src/svf/svf_flex.c diff --git a/jtag/doc/UrJTAG.txt b/jtag/doc/UrJTAG.txt index 9cf166dd..2470da59 100644 --- a/jtag/doc/UrJTAG.txt +++ b/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 =====