[Openocd-development] Trunk broken for interfaces without the speed_div function
Hi, The trunk is currently broken for interfaces without the speed_div function (interface specific clock speed value to kHz conversion). Example: parport. The attached patch fixes this. Best regards Jonas Hörberg unsupported_speed_div.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Trunk broken for interfaces without the speed_div function
Committed. Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm11 hangs jtag scan if there is no valid image in boot flash
On Sat, Aug 22, 2009 at 11:22 PM, michal smulskimichal.smul...@ooma.com wrote: I got it working with jtag_khz 10 command. It seems that when C100 runs at 24MHz, default JTAG speed is too fast. I have another question. When JTAG dongle (I use Olimex) first connects to the board it asserts srst signal even before jtag chain scan. Is there a way to turn it off. I would like to be able to connect to the target to see its state. The only way I can do this now is by disconnecting srst from board reset. OpenOCD supports some hotplugging, but I would expect the target state to change when you connect the JTAG debugger. I recommend buying an extra interface and keep it connected rather than try to hotplug to that extent. Also, is there a way to set how long the srst is kept asserted? Typical scope food. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + beagle
Could you post a list of those patches that are ready to be committed? Thanks! It would be great to focus this list one or a few remaining issues -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] BeagleBoard status, was: 0.3.0 status check
On Sun, Aug 23, 2009 at 3:07 PM, Dirk Behmedirk.be...@googlemail.com wrote: Øyvind Harboe wrote: What is the status on Beagleboard? https://lists.berlios.de/pipermail/openocd-development/2009-August/010035.html It would be nice to have some solid progress on that long standing item Yes! I'd vote to apply the four patches mentioned in the link above. One of those patches significantly modifies the behavior of a TLR reset for *all* targets. That's a bit scary... I'm hoping that David will post a list of those patches that *can* go in immediately so we get a residual list of patches to focus the list on. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Compiler error in svf.c:659
Hello, Latest source (R2606) does not compile under Windows+Cygwin - fails with error about possibly uninitialized use of variable 'ch'. Attached patch fixes this. Kind regards, Audrius Urmanavicius svf_c_variable_init_fix.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] svn code review part 2
Hello,
This is my last set of findings from looking through the code in svn. This set
mostly concentrates on variable tests that are unnecessary or could be copy
and paste issues.
In src/helper/jim.c at line 6066 we find this code:
if (end) {
then at 6071, we find this:
} else if (!end index 0)
The check for !end is unnecessary since the first check leaves no doubt that
end is 0 if it gets to line 6071.
--
src/helper/jim.c at line 7066 floats are being tested for equality.
-
src/helper/jim.c at line 9877 is this code:
if (varBObjPtr) {
farther down within the same if we find this at line 9883:
if (varBObjPtr)
Nothing in between has changed its value.
--
In src/jtag/core.c at line 717 we find this code:
if (compare_failed) {
then at line 726 we find another check of the same variable with only comments
between the two checks.
--
In src/svf/svf.c at line 1333 we find this code:
if (NULL == path)
{
LOG_ERROR(not enough memory);
return ERROR_FAIL;
Then farther down at line 1376 is
if (NULL != path)
Due to the check at line 1333, this is not necessary.
---
In src/flash/flash.c at line 700, we find this code:
if (retval != ERROR_OK)
{
image_close(image);
return retval;
Then farther down at line 711, we find this:
if (retval == ERROR_OK)
Due to the check at 700, this will always be true. There is also a repeat of
this problem at lines 826/831.
---
In src/flash/davinci_nand.c at line 648 we find this code:
chip = strtoul(argv[2], ep, 0);
if (*ep || chip == 0 || chip == ULONG_MAX) {
LOG_ERROR(Invalid NAND chip address %s, argv[2]);
goto fail;
Then at line 665 we find this:
aemif = strtoul(argv[4], ep, 0);
if (*ep || chip == 0 || chip == ULONG_MAX) {
LOG_ERROR(Invalid AEMIF controller address %s, argv[4]);
goto fail;
Its checking chip again. Is that a copy and paste mistake?
---
In src/flash/mflash.c at line 345 is this code:
if ((ret = mg_dsk_wait(mg_io_wait_drq, MG_OEM_DISK_WAIT_TIME_NORMAL)) !=
ERROR_OK)
return ret;
Then at line 355 is this:
if (ret != ERROR_OK)
return ret;
The check at line 345 should have made checking this again unnecessary. Was
the call to target_read_memory supposed to have been checked or is this just
left over code?
Best Regards,
-Steve
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.2.0 : Olimex ARM-USB-TINY - unable to find driver software
1st of all - write to the list I am using ARM-USB-TINY http://www.olimex.com/dev/pdf/ARM-USB-OCD.pdf from Olimex and AT91sam7s256 boards from Olimex. It does not have any additional converters I suppose and its a simple jtag. When I connect it to the PC(Windows Vista) I can see two '?' with the name of the jtag in the computer-manage. It does have a USB = RS-232 converter. FT2232 is like 2 devices in one chip - one is the JTAG (that's FT2232 channel A), and the other is RS-232 converter (that's FT2232 channel B). Those two devices can (and in this case - should) have different drivers, for example libusb-win32 for JTAG, original FTDI drivers for RS-232 channel. Do you mean I am on right track and modified inf file is correct? And I need to install the driver only once ? the inf file is fine, but you need the original drivers for the RS-232 channel. You may of course ignore that channel if you don't need it. Please help as I am very much troubled by this issue at the hand. Also I could not find any step by step tutorial on how to make openOCD work based on your 0.2.0 installer. This release works just as any other OpenOCD release. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.2.0 : Olimex ARM-USB-TINY - unable to find driver software
On Monday 24 August 2009, Freddie Chopin wrote: It does have a USB = RS-232 converter. FT2232 is like 2 devices in one chip - one is the JTAG (that's FT2232 channel A), and the other is RS-232 converter (that's FT2232 channel B). Those two devices can (and in this case - should) have different drivers, for example libusb-win32 for JTAG, original FTDI drivers for RS-232 channel. What makes it TINY is that channel B is unused ... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD for Windows issues
As some of you have probably noticed every now and then a questions pops up about how to use OpenOCD in Windows? Surely people refer to the release that I've made, which uses - just as some of you decided - libusb-win32 drivers. That's exactly what I was talking about some time ago when some of ppl here said that GPL is the most important thing in the world. Actually I'm answering such questions several times a week and all of them are more or less the same - here, privately, on sparkfun on other forums... When there was a release which used the normal drivers, I haven't seen ANY question about driver issues, nowhere. Currently I can say that my installer is the only Windows package of OpenOCD available on the net. A month (+/-) after publishing it was downloaded over 1400 times from my website. Keep on ignoring the Windows users. This artificially created problem just won't solve by itself. 4\/3!! For reference: http://forum.sparkfun.com/viewtopic.php?p=78567#78567 http://forum.sparkfun.com/viewtopic.php?p=79124#79124 https://lists.berlios.de/pipermail/openocd-development/2009-August/010034.html https://lists.berlios.de/pipermail/openocd-development/2009-August/009847.html Some fine quotes: They are two thing that I don't like is the speed of the jtag, with the 0.1.0 the download of my program take 20sec, but with 0.2.0 it take 75sec and I uses the same config file I have decided to create a step by step guide to build OpenOCD 0.2.0 for Windows using Cygwin (a Linux-like environment for Windows). It is linked against FTDI's proprietary (non-GPL) FTD2XX Driver to support FT2232x based JTAG interfaces. This is to (respectfully) protest against a fundamentalist enforcement of the GPL license (as opposed to being pragmatic) that has stopped the distribution of OpenOCD executables linked to ftd2xx.lib :( http://piconomic.berlios.de/build_openocd.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD for Windows issues
I love the wikipedia reference to fundamentalist and pragmatic. I didn't see any reference to terrorist, unamerican or patriotic though. :-) On a more serious note: such build instructions is one of the recommended and acceptable approaches to mitigating the problem. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD for Windows issues
I think those questions just reflect the fact that the distributions based on libftdi on Windows still have rough edges. Which should be no surprise. Such stuff takes a bit of time to sort out. On Monday 24 August 2009, Freddie Chopin wrote: This is to (respectfully) protest against a fundamentalist enforcement of the GPL license (as opposed to being pragmatic) that has stopped the distribution of OpenOCD executables linked to ftd2xx.lib For the record, it's a misnomer to call that fundamentalist. There's no assertion that other licenses are inappropriate for OTHER code; no pretense that GPL is the sole valid license to apply to any software whatsoever. What's there is instead just truthful and self-evident assertion that *this* code has a specific license, which must be obeyed like any other licence on any other code must be obeyed. It's pragmatic to insist that the license be obeyed, since there are negative legal consequences to not doing so. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD for Windows issues
Freddie, I appreciate all the effort that you have put into the Windows build, and I hope you will continue to work with the community to improve it. That does not make it acceptable for you to continue trolling here. You are the one creating a problem here, antagonizing those of us who want to respect the GPL license by attempting to label us as fundamentalists. I laugh at your obvious attempt at provocation. If you have to answer questions over and over, then -- it seems quite clear to me -- that your documentation fails to cover the required procedures in sufficient detail or clarify. That is not our failing. It is yours -- if only for failing to provide patches that answer the questions that you claim to be getting. Your attempt to blame the community for these shortcomings is positively unacceptable and immature, and you look like a real jerk from where I am sitting. Let me blunt: Fix the problems. Stop whining. I will not ignore Windows users, unless they behave like you have. Trolling is not now, nor will it ever be, acceptable in this community. So knock it off. Cheers, Zach P.S. I don't care what the problems are, since you apparently prefer to bitch about them than to help to fix them. This is directly a result of trolling rather than being constructive, but I am still willing to help those who help themselves. You aren't. This is the last reply you will get from me until you change your attitude and approach this community with more respect. On Mon, 2009-08-24 at 17:51 +0200, Freddie Chopin wrote: As some of you have probably noticed every now and then a questions pops up about how to use OpenOCD in Windows? Surely people refer to the release that I've made, which uses - just as some of you decided - libusb-win32 drivers. That's exactly what I was talking about some time ago when some of ppl here said that GPL is the most important thing in the world. Actually I'm answering such questions several times a week and all of them are more or less the same - here, privately, on sparkfun on other forums... When there was a release which used the normal drivers, I haven't seen ANY question about driver issues, nowhere. Currently I can say that my installer is the only Windows package of OpenOCD available on the net. A month (+/-) after publishing it was downloaded over 1400 times from my website. Keep on ignoring the Windows users. This artificially created problem just won't solve by itself. 4\/3!! For reference: http://forum.sparkfun.com/viewtopic.php?p=78567#78567 http://forum.sparkfun.com/viewtopic.php?p=79124#79124 https://lists.berlios.de/pipermail/openocd-development/2009-August/010034.html https://lists.berlios.de/pipermail/openocd-development/2009-August/009847.html Some fine quotes: They are two thing that I don't like is the speed of the jtag, with the 0.1.0 the download of my program take 20sec, but with 0.2.0 it take 75sec and I uses the same config file I have decided to create a step by step guide to build OpenOCD 0.2.0 for Windows using Cygwin (a Linux-like environment for Windows). It is linked against FTDI's proprietary (non-GPL) FTD2XX Driver to support FT2232x based JTAG interfaces. This is to (respectfully) protest against a fundamentalist enforcement of the GPL license (as opposed to being pragmatic) that has stopped the distribution of OpenOCD executables linked to ftd2xx.lib :( http://piconomic.berlios.de/build_openocd.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Board support for mini2440 (friendlyARM) samsung s3c2440 based board
Hi All, I hope this is what you are looking for.. attached is the final file mini2440.cfg and the diff which shows the changes from the previous version. Please let me know if that is what you're looking for. Best! Brian On Wed, Aug 19, 2009 at 2:31 PM, Øyvind Harboe oyvind.har...@zylin.comwrote: On Wed, Aug 19, 2009 at 8:01 PM, Brian Findlayfindlaybr...@gmail.com wrote: Yes, I realized I misunderstood what it's purpose was.. Please provide a patch once you have a finalized version of the config file. Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com 120d119 jtag_rclk 3000 mini2440.cfg Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD for Windows issues
Freddie, I hope you will expand the INF files as people (like me) who provide the updates they needed to make to get things working. I think the finest quotes are from people who are happy it is working http://lists.berlios.de/pipermail/openocd-development/2009-August/009851.htm l as opposed to what you quoted unhappy with the download speed Those who need real speed can build it for themselves or use Linux I bet the majority of the 1400 downloads just want something that works Thanks for the distribution, it really helped me. tom -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Zach Welch Sent: Monday, August 24, 2009 2:10 PM To: Freddie Chopin Cc: openocd-development Subject: Re: [Openocd-development] OpenOCD for Windows issues Freddie, I appreciate all the effort that you have put into the Windows build, and I hope you will continue to work with the community to improve it. That does not make it acceptable for you to continue trolling here. You are the one creating a problem here, antagonizing those of us who want to respect the GPL license by attempting to label us as fundamentalists. I laugh at your obvious attempt at provocation. If you have to answer questions over and over, then -- it seems quite clear to me -- that your documentation fails to cover the required procedures in sufficient detail or clarify. That is not our failing. It is yours -- if only for failing to provide patches that answer the questions that you claim to be getting. Your attempt to blame the community for these shortcomings is positively unacceptable and immature, and you look like a real jerk from where I am sitting. Let me blunt: Fix the problems. Stop whining. I will not ignore Windows users, unless they behave like you have. Trolling is not now, nor will it ever be, acceptable in this community. So knock it off. Cheers, Zach P.S. I don't care what the problems are, since you apparently prefer to bitch about them than to help to fix them. This is directly a result of trolling rather than being constructive, but I am still willing to help those who help themselves. You aren't. This is the last reply you will get from me until you change your attitude and approach this community with more respect. On Mon, 2009-08-24 at 17:51 +0200, Freddie Chopin wrote: As some of you have probably noticed every now and then a questions pops up about how to use OpenOCD in Windows? Surely people refer to the release that I've made, which uses - just as some of you decided - libusb-win32 drivers. That's exactly what I was talking about some time ago when some of ppl here said that GPL is the most important thing in the world. Actually I'm answering such questions several times a week and all of them are more or less the same - here, privately, on sparkfun on other forums... When there was a release which used the normal drivers, I haven't seen ANY question about driver issues, nowhere. Currently I can say that my installer is the only Windows package of OpenOCD available on the net. A month (+/-) after publishing it was downloaded over 1400 times from my website. Keep on ignoring the Windows users. This artificially created problem just won't solve by itself. 4\/3!! For reference: http://forum.sparkfun.com/viewtopic.php?p=78567#78567 http://forum.sparkfun.com/viewtopic.php?p=79124#79124 https://lists.berlios.de/pipermail/openocd-development/2009-August/010034.ht ml https://lists.berlios.de/pipermail/openocd-development/2009-August/009847.ht ml Some fine quotes: They are two thing that I don't like is the speed of the jtag, with the 0.1.0 the download of my program take 20sec, but with 0.2.0 it take 75sec and I uses the same config file I have decided to create a step by step guide to build OpenOCD 0.2.0 for Windows using Cygwin (a Linux-like environment for Windows). It is linked against FTDI's proprietary (non-GPL) FTD2XX Driver to support FT2232x based JTAG interfaces. This is to (respectfully) protest against a fundamentalist enforcement of the GPL license (as opposed to being pragmatic) that has stopped the distribution of OpenOCD executables linked to ftd2xx.lib :( http://piconomic.berlios.de/build_openocd.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD for Windows issues
Zach Welch pisze: You are the one creating a problem here, antagonizing those of us who want to respect the GPL license by attempting to label us as fundamentalists. Did I say something like that? Where? The build tutorial is not mine [; I've just found it posted on sparkfun. I laugh at your obvious attempt at provocation. Have a good laugh. I also have some good laugh resons, so let us laugh together. If you have to answer questions over and over, then -- it seems quite clear to me -- that your documentation fails to cover the required procedures in sufficient detail or clarify. That is not our failing. It is yours -- if only for failing to provide patches that answer the questions that you claim to be getting. There is no documentation from my side - I just created the installer and the basic frame for the libusb-win32 .inf files. I just don't see any failure here. Or maybe just participating in that project is a failure? You know that I don't need to be doing anything for the community, so... ? Your attempt to blame the community for these shortcomings is positively unacceptable and immature, and you look like a real jerk from where I am sitting. Oh, you got angry and irritated [; That's how the Windows users feel when dealing with libusb-win32 drivers. I'm not blaming anyone, I'm just showing you the consequence of your decisions. Name it the law, we name it with other words. Fix the problems. You mean like do a release with ftd2xx.dll and post that online? : Sorry, I'm not capable of any other fixes that would satisfy your interpretation of GPL. I'm not a PC programmer, I have no knowledge of USB protocol, JTAG layers and so on... I'm merely just a little more than a regular user. You, on the other hand, are ignoring the problem, despite what you tell. Since the time of that whole mess emerging I haven't noticed ANY movements from ANY developer to improve the situation. From my point of view you are just waiting for the problem to be covered in dust. And I remember you stating that the fix is relatively easy... Stop whining. Stop telling me what to do. I'm not telling you what you should do, so just do the same for me. I will not ignore Windows users, unless they behave like you have. I guess that they must have misbehaved then. P.S. I don't care what the problems are, since you apparently prefer to bitch about them than to help to fix them. Again (fourth time? fifth time?) - I CANNOT FIX THE PROBLEM. Believe me - FT2232 will be withdrawn from production by the time I'll learn the skills needed to fix that issue. Only YOU - the Developers of OpenOCD, libusb and libftdi - can, but somehow you just don't want to. I am still willing to help those who help themselves. You aren't. I've helped myself and use my custom built OpenOCD 0.2.0 with ftd2xx.dll : I have no business in improving OpenOCD's popularity on the major OS on the market. Yet, somehow I'm involved in that. This is the last reply you will get from me until you change your attitude and approach this community with more respect. Whatever, reply or don't - your reply won't change anything in the status quo, as there is nothing going on in that field. Name it lack of respect, I name it reminder about those who just use your software. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 FT2232 jtag power-up bug for various ARMs
As of r2606 this problem is fixed. It was fixed somewhere betweend r2584 (which has this bug) and the current trunk. The problem was introduced somewhere between r2498 and 0.2.0. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Compiler error in svf.c:659
Audrius Urmanavičius pisze: Latest source (R2606) does not compile under Windows+Cygwin - fails with error about possibly uninitialized use of variable 'ch'. Attached patch fixes this. I've just found the same issue and was about to post a patch [; The exact error is: svf.c: In function `handle_svf_command': svf.c:659: warning: 'ch' might be used uninitialized in this function make[3]: *** [svf.lo] Error 1 The fix from Audrius' patch works fine (why shouldn't it (; ) 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD for Windows issues
I'm seeing the signals as well. People start to complain about the OpenOCD Windows build lacking ftdi support. Just don't shoot the messenger. Nico Coesel -Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de namens Øyvind Harboe Verzonden: ma 8/24/09 18:16 Aan: Freddie Chopin CC: openocd-development Onderwerp: Re: [Openocd-development] OpenOCD for Windows issues On a more serious note: such build instructions is one of the recommended and acceptable approaches to mitigating the problem. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] PATCH: XScale vector table handling / Linux kernel debugging
Hi,
it seems the XScale vector table handling code in OpenOCD is only partially
implemented: the code to use user-provided vectors is there, but there is no
way to set these variables, and also no code that syncs the cached vectors
with the RAM contents.
The attached patch adds a xscale vector_table command that allows to set
the values that are written in the mini-IC (plus documentation updates that
describe why this is needed).
Using the correct values, I can now start and debug a Linux kernel on my
IXP425 board from openocd - this would before crash after uncompressing
kernel, because the cached exception vectors were completely off.
This is only tested on big-endian IXP42x, but even if it does not work on
other CPUs, it should not break any existing functionality.
cu
Michael
Index: src/target/xscale.c
===
--- src/target/xscale.c (revision 2606)
+++ src/target/xscale.c (working copy)
@@ -5,6 +5,9 @@
* Copyright (C) 2007,2008 Ãyvind Harboe *
* oyvind.har...@zylin.com *
* *
+ * Copyright (C) 2009 Michael Schwingen *
+ * mich...@schwingen.org *
+ * *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
* the Free Software Foundation; either version 2 of the License, or *
@@ -3384,6 +3387,65 @@
}
+int xscale_handle_vector_table_command(command_context_t *cmd_ctx, char *cmd, char **args, int argc)
+{
+ target_t *target = get_current_target(cmd_ctx);
+ armv4_5_common_t *armv4_5;
+ xscale_common_t *xscale;
+ int err = 0;
+
+ if (xscale_get_arch_pointers(target, armv4_5, xscale) != ERROR_OK)
+ {
+ return ERROR_OK;
+ }
+
+ if (argc == 0) /* print current settings */
+ {
+ int idx;
+
+ command_print(cmd_ctx, active user-set static vectors:);
+ for (idx = 1; idx 8; idx++)
+ if (xscale-static_low_vectors_set (1 idx))
+command_print(cmd_ctx, low %d: 0x%x, idx, xscale-static_low_vectors[idx]);
+ for (idx = 1; idx 8; idx++)
+ if (xscale-static_high_vectors_set (1 idx))
+command_print(cmd_ctx, high %d: 0x%x, idx, xscale-static_high_vectors[idx]);
+ return ERROR_OK;
+ }
+
+ if (argc != 3)
+ err = 1;
+ else
+ {
+ int idx;
+ uint32_t vec;
+ idx = strtoul(args[1], NULL, 0);
+ vec = strtoul(args[2], NULL, 0);
+
+ if (idx 1 || idx = 8)
+ err = 1;
+
+ if (!err strcmp(args[0], low) == 0)
+ {
+ xscale-static_low_vectors_set |= (1idx);
+ xscale-static_low_vectors[idx] = vec;
+ }
+ else if (!err (strcmp(args[0], high) == 0))
+ {
+ xscale-static_high_vectors_set |= (1idx);
+ xscale-static_high_vectors[idx] = vec;
+ }
+ else
+ err = 1;
+ }
+
+ if (err)
+ command_print(cmd_ctx, usage: xscale vector_table high|low index code);
+
+ return ERROR_OK;
+}
+
+
int xscale_handle_trace_buffer_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc)
{
target_t *target = get_current_target(cmd_ctx);
@@ -3692,6 +3754,7 @@
register_command(cmd_ctx, xscale_cmd, dcache, xscale_handle_idcache_command, COMMAND_EXEC, ['enable'|'disable'] the DCache);
register_command(cmd_ctx, xscale_cmd, vector_catch, xscale_handle_vector_catch_command, COMMAND_EXEC, mask of vectors that should be catched);
+ register_command(cmd_ctx, xscale_cmd, vector_table, xscale_handle_vector_table_command, COMMAND_EXEC, high|low index code set static code for exception handler entry);
register_command(cmd_ctx, xscale_cmd, trace_buffer, xscale_handle_trace_buffer_command, COMMAND_EXEC, enable | disable ['fill' [n]|'wrap']);
Index: doc/openocd.texi
===
--- doc/openocd.texi (revision 2606)
+++ doc/openocd.texi (working copy)
@@ -4877,6 +4877,52 @@
@subsection XScale specific commands
@cindex XScale
+Some notes about the debug implementation on the XScale CPUs:
+
+The XScale CPU provides a special debug-only mini-instruction cache
+(mini-IC) in which exception vectors and target-resident debug handler
+code are placed by OpenOCD. In order to get access to the CPU, OpenOCD
+must point vector 0 (the reset vector) to the entry of the debug
+handler. However, this means that the complete first cacheline in the
+mini-IC is marked valid, which makes the CPU fetch all exception
+handlers from the mini-IC, ignoring the code in RAM.
+
+OpenOCD currently does not sync the mini-IC entries with the RAM
+contents (which would fail anyway while the target is running), so
+the user must provide appropriate values using the @code{xscale
+vector_table} command.
+
+It is recommended to place a pc-relative indirect branch in the vector
+table, and put
Re: [Openocd-development] J-Link Reset Init Issue
Hi Gary, You are right, it is broken. I compiled a couple of older versions to see when it broke. Revision 2600 was working correctly, rev. 2604 did not work correctly. So I looked was has been changed and found that the target/at91sam9260.cfg was changed. While playing around with this file, I discoverd that changing the jtag_ntrst_delay back to 200 solved the problem. I have included a patch that will just do that. I hope this will work for you too! Have fun! Ferdinand Gary Carlson schreef: Hi Ferdinand, Seeing as how you are playing with Atmel parts like I am using openocd, I wanted to ask whether the reset halt and reset init are working for your setup using the latest subversion? They are broken again for me, but I didn't want to go searching for the problem until I confirmed someone else is also experiencing the problem. If you could try this out on your setup and let me know, I would appreciate it! :) Thanks, Gary Gary Carlson Gary Carlson, MSEE Principal Engineer Carlson-Minot Inc. Index: tcl/target/at91sam9260.cfg === --- tcl/target/at91sam9260.cfg (revision 2606) +++ tcl/target/at91sam9260.cfg (working copy) @@ -27,7 +27,7 @@ jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID jtag_nsrst_delay 300 -jtag_ntrst_delay 10 +jtag_ntrst_delay 200 jtag_rclk 3 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Cygwin compile warnings
Hi all,
Cygwin is giving me some compile warnings (and stops compiling on these
warnings).
I have made a patch for these warnings (see attached file:
cycgwin_warnings.patch)
An other warning is about a variable, which could be uninitialized in
this function. I also created a path for this one, but I'm not sure it
is the correct way to solve this problem. (see attached file:
uninitialized_warnings.patch)
Cheers,
Ferdinand
Index: src/svf/svf.c
===
--- src/svf/svf.c (revision 2606)
+++ src/svf/svf.c (working copy)
@@ -656,7 +656,7 @@
static int svf_copy_hexstring_to_binary(char *str, uint8_t **bin, int
orig_bit_len, int bit_len)
{
int i, str_len = strlen(str), str_hbyte_len = (bit_len + 3) 2;
- uint8_t ch;
+ uint8_t ch=0;
if (ERROR_OK != svf_adjust_array_length(bin, orig_bit_len, bit_len))
{
Index: src/target/target.c
===
--- src/target/target.c (revision 2606)
+++ src/target/target.c (working copy)
@@ -1760,7 +1760,7 @@
value = buf_to_str(reg-value,
reg-size, 16);
command_print(cmd_ctx,
- (%i) %s (/%u): 0x%s%s,
+ (%i) %s (/% PRIu32
): 0x%s%s,
count, reg-name,
reg-size, value,
reg-dirty
@@ -1768,7 +1768,7 @@
: );
free(value);
} else {
- command_print(cmd_ctx, (%i) %s (/%u),
+ command_print(cmd_ctx, (%i) %s (/%
PRIu32 ),
count, reg-name,
reg-size) ;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] warning fix
Simple..
- Duane.
Index: src/target/target.c
===
--- src/target/target.c (revision 2606)
+++ src/target/target.c (working copy)
@@ -1760,7 +1760,7 @@
value = buf_to_str(reg-value,
reg-size, 16);
command_print(cmd_ctx,
- (%i) %s (/%u): 0x%s%s,
+ (%i) %s (/% PRIu32
): 0x%s%s,
count, reg-name,
reg-size, value,
reg-dirty
@@ -1768,7 +1768,7 @@
: );
free(value);
} else {
- command_print(cmd_ctx, (%i) %s (/%u),
+ command_print(cmd_ctx, (%i) %s (/%
PRIu32 ),
count, reg-name,
reg-size) ;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD for Windows issues
On Tue, Aug 25, 2009 at 2:09 AM, Zach Welchz...@superlucidity.net wrote: Freddie, I appreciate all the effort that you have put into the Windows build, and I hope you will continue to work with the community to improve it. I think we should all appreciate the efforts of Freddie. He could have take off the download links altogether. If you have to answer questions over and over, then -- it seems quite clear to me -- that your documentation fails to cover the required procedures in sufficient detail or clarify. That is not our failing. It is yours -- if only for failing to provide patches that answer the questions that you claim to be getting. I will think building instructions for Windows users should be part of the project. And it should be improved. It is not Freddie's failure. The project team should help on this topic. Let me blunt: Fix the problems. We need to work together to fix the problem. Since it can not be fixed in a short time, we should first improve on the documents to mitigate the problems. Stop whining. I will not ignore Windows users, unless they behave like you have. Trolling is not now, nor will it ever be, acceptable in this community. So knock it off. I understand that some of the developers have stronger views on the license topic. But we have to admit that there is a problem. As David mentioned: I think those questions just reflect the fact that the distributions based on libftdi on Windows still have rough edges. Which should be no surprise. Such stuff takes a bit of time to sort out. So please calm down and do not be too harsh in your emails. Just don't shoot the messenger, as said by Nico. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] BeagleBoard and Flyswatter
hi, http://elinux.org/BeagleBoardOpenOCD reports success with using OpenOCD and the Flyswatter to establish a JTAG connection with the Beagle board. I've tried to reproduce these steps but am having some issues. After contacting one of the authors of the http://elinux.org/BeagleBoardOpenOCD , I was directed to: https://lists.berlios.de/pipermail/openocd-development/2009-June/008256.html Key thing here was a patch to the jtag/core.c file. After applying this patch, I was able to establish a JTAG connection. Next I tried the omap3_dbginit command from a telnet connection. What I get is the following message repeated constantly. Any ideas? gu...@fred-desktop:~$ telnet localhost Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger scan_chain TapName| Enabled | IdCode ExpectedIrLen IrCap IrMask Instr ---| | -|||--|--|--|- 0 | omap3530.dsp |n| 0x | 0x | 0x26 | 0x25 | 0x3f | 0x 1 | omap3530.dap |n| 0x | 0x0b6d602f | 0x04 | 0x01 | 0x0f | 0x0f 2 | omap3530.jrc |Y| 0x0b7ae02f | 0x0b7ae02f | 0x06 | 0x01 | 0x3f | 0x3f omap3_dbginit JTAG tap: omap3530.jrc tap/device found: 0x0b7ae02f (mfg: 0x017, part: 0xb7ae, ver: 0x0) JTAG Tap/device matched AHBAP Cached values: dp_select 0x0, ap_csw 0xa212, ap_tar 0x SWJ-DP STICKY ERROR Read MEM_AP_CSW 0x2800052, MEM_AP_TAR 0xe000ed00 AHBAP Cached values: dp_select 0x0, ap_csw 0xa212, ap_tar 0x SWJ-DP STICKY ERROR Read MEM_AP_CSW 0x2800052, MEM_AP_TAR 0xe000ed00 Block read error address 0xe000ed00, count 0x1 AHBAP Cached values: dp_select 0x10, ap_csw 0xa202, ap_tar 0xe000edf0 SWJ-DP STICKY ERROR Read MEM_AP_CSW 0x2800042, MEM_AP_TAR 0xe000edf0 TargetName Type Endian TapNameState -- -- -- -- -- 0* omap3.cpu cortex_m3 little omap3530.dap unknown 0x54011314 0009 0x54011314 0009 AHBAP Cached values: dp_select 0x10, ap_csw 0xa202, ap_tar 0xe000edf0 SWJ-DP STICKY ERROR Read MEM_AP_CSW 0x2800042, MEM_AP_TAR 0xe000edf0 AHBAP Cached values: dp_select 0x10, ap_csw 0xa202, ap_tar 0xe000edf0 SWJ-DP STICKY ERROR fred ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
