Re: [Openocd-development] If no -expected-id's listed then do not check

2009-09-30 Thread David Brownell
On Tuesday 29 September 2009, Øyvind Harboe wrote: If no -expected-id's listed then do not check ID's. Not really. First, there's the BYPASS case. Second, it isn't not checking ... it's just spewing different noise than came from the message posted earlier today. (And not what I'd call better

Re: [Openocd-development] OUT macro redefined under MinGW

2009-09-30 Thread Nico Coesel
From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of David Brownell Sent: dinsdag 29 september 2009 20:44 To: simon qian Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] OUT macro redefined under

Re: [Openocd-development] If no -expected-id's listed then do not check

2009-09-30 Thread Øyvind Harboe
OK. I'm convinced that we're in pretty good shape now and that we should let this be until the next crossroads. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development

Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling

2009-09-30 Thread Magnus Lundin
We can, and sometimes we want to, write to memory while the CortexA8 core is running, but for gbd to load a program and the i-caches to be cleared to core must be halted. So I think there must be a monitor halt after the monitor omap3_dbginit No. I just do arm-none-linux-gnueabi-gdb

Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling

2009-09-30 Thread Dirk Behme
Magnus Lundin wrote: We can, and sometimes we want to, write to memory while the CortexA8 core is running, but for gbd to load a program and the i-caches to be cleared to core must be halted. Yes, thanks! Attachment now gives me: -- cut -- arm-none-linux-gnueabi-gdb GNU gdb 6.8 Copyright

Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling

2009-09-30 Thread Magnus Lundin
David Brownell wrote: 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. I have done some more testing and trying to understand the reset handling in

Re: [Openocd-development] srst state on init again

2009-09-30 Thread Øyvind Harboe
1. put reset_on_init patch that I submitted earlier and make it dependent on hardware used to access JTAG. Where is this patch? 2. put in udev rules a small program that will de-assert srst. I am not sure if would be committed to openocd tree? Comments or ideas? Remove the initial scan of