Hi Duane, Thanks for your feedback.
El Mar 13, 2009, a las 04:30 , Duane Ellis escribió: > -Duane. > > In general - looks good. > > We should break the changes up a little bit. Smaller change sets are > less messy. Now that I'm plugged into the process, in the future I'll submit smaller bits of work more frequently. Tho' for this new part this patch does represent what's needed to make it work with OpenOCD. > > > 1) for a commit - 'experimental code' needs to not be present. > no big deal at this stage of the game. > that or - tell us more about what's going on here. Good point. I'll make sure to clip that stuff next time. > > > 2) jtag/jtag.h. changing state numbers concerns me - but i see > *exactly* why you are doing this. > Perhaps this sort of stuff would have helped earlier with the beagle > board work. > And it looks like a good idea. > > I'd like others to comment also. > (*HEY* anybody else reading this?*) > > ie: ?DIRK/DICK? I forget who - wrote quite a bit of stuff with an > SVF playback > code to do xilinx stuff. I'd hate to break that... This is a big factor in the JLink working correctly, because it seems the MC1322x has a low tolerance for anything not following the letter of the official spec. I'm not an ARM or JTag expert (yet) but I chalk this narrow window to being normal for a new part. > > > 3) the state numbers - could you put a better reference in. > Example: The state numbers are from: > Document: ARM 7TDMI Technical Reference Manual > Revision: R4P1 > Section: B.1.2 > Arm Document ID Number: DDI 0210C > Good point. > 5) Lots of thumb clean up code - I've not used much thumb code. > You probably found a number of issues :-) > I guess you are doing everything in THUMB mode eh? > I've found a few issues too. > > What's going on? Can you explain more about this part of your > changes? Yes, lot's of thumb code. This is a tiny MCU with just 80K RAM. I have a hunch of what's going on, but since I can't see the internals of the EICE there's no way for me prove it other than seeing side effects. My understanding is that all "t" MCUs explode the 16 bit code into fully qualified 32 bit code just prior to exec. I'm wondering if there is some mixup in the pipeline (steps added/removed) that causes the EICE and the core to get out of synch compared to a pure 32-bit program. There are already some known (but not yet acknowledged) bugs with the EICE in this part. I'll need more experiences with the part to know for sure. > > > 6) Your "Debug state machine()" - in jlink.c - looks useful for > other > things :-) > Is that really just dis-assembling the command byte stream to the > jlink? This was my tutor! :-) I wrote this first to instruct me on the flow and function of OpenOCD. I think it's very useful, but I didn't see a good way of making it general to all converters. Perhaps we can work together on this. If you turn on all of the debugging you'll see the program becomes a virtual teacher of the whole pod->JTAG->EICE->MCU chain. > 7) Why the "10 second" - vrs 1 second timeout in arm7_9_common.c? > Is this because you are running the jtag clock slow? Or is this > something else? > Is it the jtag clock rate? Or are you trying to do a lot of stuff? > 10 seconds is an eternity to somebody who does not know/understand > what is going on and causes confusion. > ie: Human Factors, nothing technical ... > Because I kept wanting to dump the entire RAM at 1KHz! :-) Perhaps the right thing to do here is to time out after one second of nothing received instead of one second for the entire op. > 8) Longer term issue - is host byte order - ie: the hard coded ARM > NOP > you added: "default_nop_out" > > Oh, I'm liable to make a lot of mistakes until I gain some experience here. I appreciate the feedback. Sergey, do you think this is the cause of the ARM9 problem you see? Were you able to try the changes I proposed? I just checked my patch against r1411, and it's still sensible if you still want to try the experiments I proposed. > So what are next steps? It seems that you may have already done the actionable stuff, and the other comments are for any further work I submit. Jeff _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
