Hi all, reading more MIPS documentation I came to certain assumptions how JTAG debugging works with these cores (EJTAG), so I'll try to answer myself for the future reference, but also as a possible motivation for someone to comment on these :
On Fri, Jan 7, 2011 at 4:06 PM, Drasko DRASKOVIC <drasko.drasko...@gmail.com> wrote: > HI all, > I have a simple question for anyone worked with MIPS (EJTAG) before - > does it support "halt" mode debugging, or ROM monitor mode is only > option ? Core will not be literary in "halt" mode, but it will enter DEBUG mode (chapter 1.3.1 Debug Exception and Debug Mode of the MIPS EJTAG Specification), a special mode with no restrictions on access to co-processors, memory areas, etc., and where usual exceptions like address error and interrupt are masked. The debug exception handler is executed in Debug Mode and provided by the debug system. It can be executed from the probe through a processor access, or may also reside in the application code if the developer chooses to use a debug task in the application. In the other words, it will be some kind of monitor debugging, but with Monitor ROM code that can be passed dynamically by the GDB via OpenOCD (via JTAG probe). > > Coming from the ARM world, I am looking for "halt" mode debugging, as > I am very limited on chip surface to add additional ROM. No additional memory place will be taken for "Monitor ROM" (if we can call it like that, because it is not real Monitor ROM) instructions, as it will not residue in on-chip ROM, nor as a section of RAM loaded ELF. These instructions will be put dynamically (during debug time) by the debugger (GDB) in the memory mapped (i.e. virtual) space called DMSEG (please refer to the chapter 5.2.2 Debug Mode Address Space of the MIPS EJTAG Specification document) . > > 1) > I read in one document : > In addition to providing a standard debug I/O interface, EJTAG > provides the following new > capabilities for software and system debug: > - Off-board EJTAG memory - A MIPS processor in Debug Mode sees EJTAG > memory mapped > as physical memory, but references to this memory are converted into > transactions on the > TAP interface. Both instructions and data can be accessed in EJTAG > memory, which allows > debugging of systems without requiring the presence of a ROM monitor > or debugger scratch > pad RAM. > > Would that mean that all CPU-s internal state can be explored using > TAP and without monitor ROM ? Well, yes and no. Not by the ARM way, but using MIPS ASM instructions passed via DMSEG memory, which is virtual and is mapped on EJTAG. So, these instructions are passed transparently from developer, via OpenOCD. > > > 2) > In Software Users Manual it is written : > The TAP modules support handling of fetches, loads and stores from the > CPU through the dmseg segment, whereby > the TAP module can operate like a slave unit connected to the on-chip > bus. The core can then execute code taken > from the EJTAG Probe and it can access data (via a load or store) > which is located on the EJTAG Probe. This occurs > in a serial way through the EJTAG interface: the core can thus execute > instructions e.g. debug monitor code, without > occupying the memory. > > What would that say, I do not quite get... That ROM monitor is finally > necessary, and there is no "halt" mode debugging ? This "ROM Monitor" code is however passed dynamically in debug time, and transparently from developer who issues high-level debugging request in GDB, which are internally in OpenOCD translated to a series of MIPS ASM instructions (ROM Monitor code) : http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob_plain;f=src/target/mips32_pracc.c;hb=94fa8fd30ae5fd29529f401e123864565591e2ed. This is so called "PrAcc" mode. Otherways, there is so called "DMA" mode which resembles more ARM debugging. CPU will still enter the DEBUG exception, and DMSEG will be become visible. But this time we will not pass MIPS ASM instructions via DMSEG for CPU to execute them and read/write memory, but will instruct DMA to do so (faster). This is also transparent for developer, as it issues high level mem read/write in GDB, and DMA commands are transparently handled by OpenOCD : http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob_plain;f=src/target/mips32_dmaacc.c;hb=94fa8fd30ae5fd29529f401e123864565591e2ed. > > 3) > Here : http://www.linux-mips.org/wiki/JTAG is written : > MIPS EJTAG has two modes, one is "DMA" mode where the JTAG can cause > CPU bus cycles directly, the other "PrAcc" is where the JTAG interface > is used to respond to CPU memory accesses in a special range of memory > (DMSEG, 0xFF200000) and you have to write little bits of MIPS code to > do what you want and emulate that memory on the host side. All systems > support PrAcc mode by nature. The DMA mode is optional and not as > widely supported as the normal mode. The presence of DMA mode is noted > in the IMPCODE register. > > Can anyone explain me what this would say " JTAG can cause CPU bus > cycles directly" ? I do not get this sentence quite even now... What did writer wanted to say with this, no idea > > Can anyone confirm me that " 'PrAcc' is where the JTAG interface is > used to respond to CPU memory accesses in a special range of memory > (DMSEG, 0xFF200000) ", which I do not quite get, would actually say > that " ROM monitor is called when breakpoint exception is hit " Not quite, because : 1) executed code is not exception handler, but MIPS ASM instructions passed by GDB/OpenOCD 2) code is not read from exception vector space, but from DMSEG (virtual mem space, which is mapped to EJTAG, i.e. JTAG probe). > and > explain what "emulate that memory on the host side" would say (I have > no idea)... Still no idea about this. What this "emulation" is supposed to be ? Hope that this will be useful, and that some MIPS guru will also comment and give additional clarifications. Best regards, Drasko _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
