2008/8/20 Duane Ellis <[EMAIL PROTECTED]>:
> Fix another warning..
Committed.
Thanks!
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-developmen
On Tue, 19 Aug 2008 21:30:58 +, Daniel Gimpelevich wrote:
> On Tue, 19 Aug 2008 10:47:30 -0400, Nicolas Pitre wrote:
>
>> So far I've always been able to halt a Feroceon based board with no
>> flash content simply by holding the reset button while performing a
>> halt on the openocd console t
Fix another warning..
-Duane.
Index: src/jtag/amt_jtagaccel.c
===
--- src/jtag/amt_jtagaccel.c(revision 947)
+++ src/jtag/amt_jtagaccel.c(working copy)
@@ -155,7 +155,7 @@
return ERROR_OK;
}
-void amt_jtagaccel_en
On Tue, 19 Aug 2008 10:47:30 -0400, Nicolas Pitre wrote:
> So far I've always been able to halt a Feroceon based board with no
> flash content simply by holding the reset button while performing a halt
> on the openocd console then quickly releasing the reset button. It
> seems that the processor
On Tue, 19 Aug 2008, Øyvind Harboe wrote:
> On Tue, Aug 19, 2008 at 4:47 PM, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > On Tue, 19 Aug 2008, Daniel Gimpelevich wrote:
> >
> >> On Tue, 19 Aug 2008 09:10:19 +0200, Øyvind Harboe wrote:
> >>
> >> > I guess there is no royal road to solving this prob
Take #3 (fixed a bug/removed warnings)
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
Index: C:/workspace/openocd/src/target/arm720t.c
===
--- C:/workspace/openocd/src/t
Take #2 at the same patch.
Testing appreciated, I'll need to test this on my own rocket don't have access
to build system/hw currently.
The added bonus here is that this could actually *increase* the performance
of many small operations as the lag from an algorithm halting to executing
continuing
On Tue, Aug 19, 2008 at 4:47 PM, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> On Tue, 19 Aug 2008, Daniel Gimpelevich wrote:
>
>> On Tue, 19 Aug 2008 09:10:19 +0200, Øyvind Harboe wrote:
>>
>> > I guess there is no royal road to solving this problem... There is a lot
>> > of necessary complexity to t
On Tue, 19 Aug 2008, Daniel Gimpelevich wrote:
> On Tue, 19 Aug 2008 09:10:19 +0200, Øyvind Harboe wrote:
>
> > I guess there is no royal road to solving this problem... There is a lot
> > of necessary complexity to the situation that just need to be grokked.
>
> Yes, and so far, nobody involved
I haven't tried this patch, but perhaps it catches your case?
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
Index: C:/workspace/openocd/src/target/arm720t.c
===
--- C:
I've committed this patch, even if it is work in progress, as
there are also other changes to jtag.c going on at this time
and synchronizing work takes priority.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
Has anyone done any XScale testing lately?
I tinkered a bit with the performance of GDB load, so it should now
be better. We're seing 400kBytes/s @ 16MHz for GDB load(on
par with what we have for ARM7/9).
XScale seems to work fine here. Tried it on a PXA255
--
Øyvind Harboe
http://www.zylin.co
Try the attached patch.
It invokes keep_alive() every 500ms when sleeping.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
Index: C:/workspace/openocd/src/jtag/jtag.c
===
How about adding a Tcl package that the target configruation script
can draw upon?
The idea is that the translation list is under OpenOCD subversion
and that the target config script adds this sort of warm-fuzzy
messages *if* it makes sense for that target?
A newcomer will have to start with a co
All,
I've often seen these number messages:
JTAG device found: 0x2190101d (Manufacturer: 0x00e, Part: 0x1901,
Version: 0x2)
I think it would be helpful if they also included
"MFG: 0x00e , Part: 0x1901 ..."
For example - the urjtag package, in the "data" directory has lots of
Comitted.
Thanks!
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd
Øyvind>Can you resubmit using svn diff?
Øyvind> I wasn't able to apply this patch.
Øyvind> Also svn diff has the added bonus
Øyvind> that it will ignore all the automake files for you...
that was the problem the last time - SVN DIFF does not include new files
that one adds.
oh well ... attache
Hi Edgar,
It worked!
All I needed to know to do it quickly without losing a night was that
http://openfacts.berlios.de/index-en.phtml?title=OpenOCD_configuration
is obsolete! I needed to read documentation from svn/doc/openocd.info!
Your hint was essential for me to see that webpage docum
I've committed a fix for the error handling in flash bank.
Execution of the startup script now terminates when flash bank fails.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
___
Openocd
Hi,
>
> At my best try, it could communicate with the arm7, but I got the
> following messages on the screen:
> Info:options.c:50 configuration_output_handler(): Command probe not
> found
> Info:options.c:50 configuration_output_handler(): Command erase not
> found
> Info:options.c:50
Hello,
I tried to upload a binary file to arm without success. I had already
uploaded successfully using parport, but now I have no more parport on
my notebook and tried using Olimex arm-usb-ocd.
I tried with:
* openocd ubuntu hardy package (came from svn r211)
* openocd ubuntu intrepid
I've committed some fixes to ARM11 error handling + target/imx31.cfg file.
I don't understand precisely what is being suggested by Dominic & Laurent
that should be done to jtag_validate_chain().
I'll be happy to take a patch for a spin I've got an iMX31 in my office.
I did try to fix jtag_examin
Hello all,
I have been trying to add a cable (called yajtag) to openOCD. I have
added the nessecary files and I can define the cable in the config
file without a problem. The cable is detected okay but the problem
happens when scanning the chain.
When I test my target (A old obselete com21 cable
>>> 3 if flash_contents <> valid_executable_code then exception_asserted=-1
>>
>> how would one check that flash does not contain valid executable code?
>
> The target CPU attempts to execute bootstrap code from flash upon power-
> on/reset, and it's not there.
1. Could you explain the above a bit
On Tue, 19 Aug 2008 09:10:19 +0200, Øyvind Harboe wrote:
>>> Can you try to boil down these discussions to the essential and
>>> relevant bits for OpenOCD & post it here?
>>
>> I thought my previous post did exactly that.
>
> I guess there is no royal road to solving this problem... There is a lo
>> Can you try to boil down these discussions to the essential and relevant
>> bits for OpenOCD & post it here?
>
> I thought my previous post did exactly that.
I guess there is no royal road to solving this problem... There is a lot
of necessary complexity to the situation that just need to be gr
On Tue, 19 Aug 2008 08:28:38 +0200, Øyvind Harboe wrote:
> Do you have any suggestions at this point as to how OpenOCD can solve
> this problem?
If so, I would test first. The only ideas I might have at this point
would involve either Byron conducting more experiments, or Nico dipping
into his
27 matches
Mail list logo
