Well, some days our work is a bit more confused then other days.

Dirk Behme wrote:
Magnus Lundin wrote:
For testing and comments:

Uses the OMAP3530 global software reset and defines corresponding reset-start and reset-end event handlers.

Something is wrong with the patch in attachment? It has to be done the inverse? I.e.

--- tcl/target/omap3530.cfg    (revision 2768)
+++ tcl/target/omap3530.cfg    (working copy)

instead of

--- tcl/target/omap3530.cfg    (working copy)
+++ tcl/target/omap3530.cfg    (revision 2768)

This was done for me by the diff program in kdesvn, and I didnt read carefully.

Additionally:

I can't find any difference (whitespace only?) in

-if { [info exists CHIPNAME] } { - set _CHIPNAME $CHIPNAME -} else { +if { [info exists CHIPNAME] } {
+   set  _CHIPNAME $CHIPNAME
+} else {

There was a whitespace patch from Dave that I had not applied on the tcl directory.
And:

omap3.cpu configure -event reset-end "omap3_dbginit"

should call omap3_reset instead of omap3_dbginit? Or who calls omap3_reset? Or why call omap3_dbginit from omap3_reset, too?

At the end of the reset handling we reinitialise the tap and the debug interface with omap3_dbginit omap3_reset is really reset+reinit+halt and you call it if you want to debug the loading of u-boot by the X-Loader

New  patch attaced.

Regards,
Magnus



Index: tcl/target/omap3530.cfg
===================================================================
--- tcl/target/omap3530.cfg	(revision 2768)
+++ tcl/target/omap3530.cfg	(working copy)
@@ -42,7 +42,6 @@
 # FIXME much of this should be in reset event handlers
 proc omap3_dbginit { } {
      poll off
-     reset
      sleep 100
 
      jtag tapenable omap3530.dap
@@ -54,3 +53,17 @@
      poll on
 }
 
+set PRM_RSTCTRL 0x48307250
+
+proc omap3_reset { } {
+	# Global software reset
+	# RST_GS bit in PRM_RSTCTRL
+	mww $PRM_RSTCTRL 2
+	omap3_dbginit
+	halt
+}
+
+omap3.cpu configure -event reset-start "omap3.cpu mww $PRM_RSTCTRL 2"
+omap3.cpu configure -event reset-end "omap3_dbginit"
+
+
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to