On Wed, Sep 22, 2010 at 12:12 PM, Drasko DRASKOVIC <[email protected]> wrote: > Hi Øyvind, > thanks very much for the comments. I just need some clarifications : > > > On Wed, Sep 22, 2010 at 12:00 PM, Øyvind Harboe <[email protected]> > wrote: >>> While fileds manipulation is intuitive, I do not get : >>> >>> 1) Why do we have to call jtag_add_dr_scan() two times, first time >>> with fields[1].in_value = NULL, other time set to correct var to which >>> we want to capture CP15 register value. What are we doing first time, >>> and what the second ? For write CP15 functions we do >>> jtag_add_dr_scan() only once, >> >> I think you need to read up in the datasheet. If you figure out why, >> then you could submit a patch with comments? > > Do you want to say that this is something specific to ARM946/966/920 > (I've seen this with all these variants) that can be found in ARM > manual, and not something specific to OpenOCD architecture and > functioning (as I was thinking) ?
Best I can suggest is that you read the documentation on how these shift registers work, then look at what the code is doing. >>> 2) Why do we put pointer to value variable in 6 bits address fields ? >>> Should not we put it to 32 bit value fields, i.e. fields[0].in_value ? >> >> If you read the datasheet, you'll find that JTAG is talking to a register >> that's 6 bits wide, I'd think. > > I know it is 6 bits wide, that can be clearly seen from the datasheet. > Question is why would we put value in _address_ fields ? > Address should be put to address part, value to value part (which is > 32 bits wide). This sounds logic to me... Address here might refer to which jtag register you're looking at. There may be several 6 bit registers accessible by JTAG? > The question is also why do we put it to we put it to in_value when we > want to read the god damn thing, not to write it. Would not out_value > be a better candidate for this pointer to hold valued that we will > read OUT of the CP 15 register ? in_value means read from JTAG and write to memory on OpenOCD host side. out_value points to data to be clocked out on JTAG. >>> 3) What is jtag_add_callback(arm_le_to_h_u32, >>> (jtag_callback_data_t)value) doing ? Why does it force little endian, >>> and how to change this since ARM946E-S is big endian. >> >> Look at how the bits inside this shift register is organized. >> >> This is correct, but a bit hackish. The code is passing in a pointer >> to uint32_t and using it as storage for an array of 4 uint8_t. >> >> After the JTAG queue has filled in *only* the first 8 bits, the >> callback will convert the array of 8 bit integers into a 32 bit >> uint32_t. > > Very difficult to see this. However, what will happen to endianess.? > Should this be touched, since my ARM946 is in BE mode ? This is not about endianess of the target, but endianness on the OpenOCD side. >>> 4) What is jtag_execute_queue() ectually doing and why is is used only >>> for debug ? >> >> jtag_execute_queue() flushes the jtag command fifo. In debug it >> can be useful to do this immediately to be able to see the values >> read from the JTAG chain in the debugger. > > I noticed that if I call this function inside CP read, than callee > gets different results than when the function is not called. So, it > looks like if not called (i.e. debug enabled), this function will > never be called otherwise, and I don't know if it is needed for > obtaining a correct result... jtag_execute_queue() is postponed as long as possible so as to make a big a jtag queue as possible => increases performance. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
