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) ? > >> 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... 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 ? > >> 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 ? > >> 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... Best regards, Drasko _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
