David Brownell wrote: > On Tuesday 29 September 2009, Magnus Lundin wrote: > >> +omap3.cpu configure -event reset-start "omap3.cpu mww $PRM_RSTCTRL 2" >> +omap3.cpu configure -event reset-end "omap3_dbginit" >> > > Isn't there a chicken/egg thing having "omap3.cpu mww ..." do > its thing without having forcibly enabled the TAP, which is > done early in omap3_dbginit? > Yes there is, but I think that when we connect to a target we just do omap3_dbginit right after init, with no reset as default. We do not always want to reset the whole system at every connection, for instance when debugging a running Linux kernel or applications.
The when we need or want we can reset the system, which of course will call omap3_dbginit again. This seems to work quite well with no recursive resets and not an endless stream of failed communication attempts. > I've not tried this patch, but I don't think there's yet a clean > way to make the current set of events handle "reset" for OMAP3. > But that "proc omap3_reset..." looks good. > > Also, my copy of the TRM says writing "2" there is a software reset, > where normally I'd want more of a cold reset (write "4") to work > around "we don't have SRST support". That's why that's there, yes? > You're using "2" in part to avoid needing a reset-init handler to > set up the DRAM controller, I suspect... > > I havn'nt really thought to much about this, first I wanted any reasonable functional reset functionality without using the hard button or the power switch. We can test both and maybe even have warm_reset (soft_reset) and cold_reset . For the OMAP3530 I think we will end up in the X-Loader that set up DRAM for us, the breakpoint registers seem to be cleared by the reset so to debug early startup we must be quick to issue the halt. Using the USB based dongle this is likely to be at least a couple of microseconds. > I think that's not quite following the model which the code in > the src/helper/startup.tcl file is expecting ... a closer match > would use reset-assert-pre (or maybe "post") not reset-start. > Same thing :) , I simply grabbed an event that was supposed to be early in the reset sequence, and one late in the sequence. Regards, Magnus _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
