Didn't know about that command. I always used the openocd commands.
This is much easier.
However, the compare fails. Here is the GDB output. I attached the
corresponding OpenOCD output to this email as it is quiet long. Any
suggestions on what went wrong?
(gdb) load
Loading section .text, size
If you try monitor verify-image filename it will print out the first
128 bytes of differences. Could give some clues.
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11
I found the problem. My GDB didn't have XML extensions (libexpat)
integrated, and thus didn't have a clue about the memory map. It's
interesting though that I didn't get any errors.
Thanks for all the help!
Thomas
___
Openocd-development mailing list
* Write to the PRM reset control register should have been 'phys';
* Setup empty reset-assert handlers for the M3's, since the board-level reset
takes care of them;
* Remove the dbginit cruft, because it gets called implicitly on reset.
Signed-off-by: Aaron Carroll aar...@cse.unsw.edu.au
---
Fixes the reset bits of omap4430.cfg. To do this properly we need to be able to
override the M3's reset sequence, as can be done already on A8/A9, ARM11, etc.
Aaron Carroll (2):
cortex_m3: allow scripts to override reset
omap4430: fix reset sequence
src/target/cortex_m3.c | 10
If a handler for the reset-assert event it present, skip the usual reset
handling. This is needed, for example, for board-level resets.
Signed-off-by: Aaron Carroll aar...@cse.unsw.edu.au
---
src/target/cortex_m3.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git
It looks like an omission in Cortex M3 to me not to
support this event and the changed code-path is
only when the event is added, so it should be pretty
robust against regressions.
Merged.
However, I'm wondering if the rest of the code in
cortex_m3_assert_reset() should not be made
available
