Re: [Openocd-development] OpenOCD + beagle
I have committed all but 01_openocd_beagle.patch to hopefully get things
moving along
01_openocd_beagle.patch is problematic because it modifies the behavior
for *all* targets.
Thoughts?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
Appended is the TCK patch I'm using. Without it ... nothing
detected on Beagle, even after resetting. With it ... nothing detected
on openocd startup, but after reset command it came up with the
expected JTAG id.
I don't consider this patch worth merging. What merges should work
right from server startup.
- Dave
---
src/jtag/core.c |4
1 file changed, 4 insertions(+)
Index: trunk_2604/src/jtag/core.c
===
--- trunk_2604.orig/src/jtag/core.c
+++ trunk_2604/src/jtag/core.c
@@ -469,6 +469,10 @@ void jtag_add_tlr(void)
{
jtag_prelude(TAP_RESET);
jtag_set_error(interface_jtag_add_tlr());
+ /* Add a bunch of clocks after TLR entry to be sure ICEpick
+ * power domain switches on.
+ */
+ jtag_set_error(interface_jtag_add_runtest(100, TAP_RESET));
jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
}
___
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
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] Compiler error in svf.c:659
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] PATCH: XScale vector table handling / Linux kernel debugging
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] J-Link Reset Init Issue
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] Cygwin compile warnings
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] [PATCH] warning fix
This is fixed in svn head now. -- Ø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 0.2.0 : Olimex ARM-USB-TINY - unable to find driver software
On Mon, Aug 24, 2009 at 9:02 PM, Freddie Chopin freddie_cho...@op.plwrote: 1st of all - write to the list 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. It might seem silly question for an experienced person but please excuse for this. Does that mean that I need to first install the the drivers which came along with the ARM-USB-TINY on a CD and then uninstall the driver for JTAG. And then install libusb-win32 for JTAG alone? Also I am unable to understand for what purpose I need the RS232 converted. My Jtag hardware's(olimex USB TINY) one end goes to USB drive and other goes to jtag socket on ARM board. It does not have an RS232port like the one mentioned here http://www.olimex.com/dev/index.html 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. Does ignoring means that I should just install the driver only once(for jtag) and on second time when prompted for drivers I should ignore it? Regards Rohit ___ 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 0.2.0 : Olimex ARM-USB-TINY - unable to find driver software
Sorry the link given by me is not a direct one. I meant following device at Olimex website: *ARM-USB-OCD* 3-IN-1 FAST USB ARM JTAG, USB-TO-RS232 VIRTUAL PORT AND POWER SUPPLY 5-9-12VDC DEVICE (SUPPORTED BY OPENOCD OPEN SOURCE ARM DEBUGGER) On Tue, Aug 25, 2009 at 12:52 PM, Rohit Chandel mygalaxy...@gmail.comwrote: On Mon, Aug 24, 2009 at 9:02 PM, Freddie Chopin freddie_cho...@op.plwrote: 1st of all - write to the list 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. It might seem silly question for an experienced person but please excuse for this. Does that mean that I need to first install the the drivers which came along with the ARM-USB-TINY on a CD and then uninstall the driver for JTAG. And then install libusb-win32 for JTAG alone? Also I am unable to understand for what purpose I need the RS232 converted. My Jtag hardware's(olimex USB TINY) one end goes to USB drive and other goes to jtag socket on ARM board. It does not have an RS232port like the one mentioned here http://www.olimex.com/dev/index.html 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. Does ignoring means that I should just install the driver only once(for jtag) and on second time when prompted for drivers I should ignore it? Regards Rohit ___ 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 0.2.0 : Olimex ARM-USB-TINY - unable to find driver software
On Tue, Aug 25, 2009 at 3:22 PM, Rohit Chandelmygalaxy...@gmail.com wrote: On Mon, Aug 24, 2009 at 9:02 PM, Freddie Chopin freddie_cho...@op.pl wrote: 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. Does ignoring means that I should just install the driver only once(for jtag) and on second time when prompted for drivers I should ignore it? It is better to install the original FTD2xx driver which Olimex provides for the 2nd channel even though it is not used. If not, there will be an ugly yellow mark on the Device Manager and you may get repeat prompt when you plug the device into different port. The FDTI device is a USB composite device. The first interface is used for the JTAG function. Even though the 2nd interface is not used for the TINY, Windows will still recognize it and ask for a driver. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] small CFI cleanup
Hi,
a small CFI cleanup bit that has been in my local version for some time.
cu
Michael
Index: src/flash/cfi.c
===
--- src/flash/cfi.c (revision 2606)
+++ src/flash/cfi.c (working copy)
@@ -74,7 +74,7 @@
static void cfi_fixup_atmel_reversed_erase_regions(flash_bank_t *flash, void *param);
/* fixup after reading cmdset 0002 primary query table */
-static cfi_fixup_t cfi_0002_fixups[] = {
+static const cfi_fixup_t cfi_0002_fixups[] = {
{CFI_MFR_SST, 0x00D4, cfi_fixup_0002_unlock_addresses, cfi_unlock_addresses[CFI_UNLOCK__2AAA]},
{CFI_MFR_SST, 0x00D5, cfi_fixup_0002_unlock_addresses, cfi_unlock_addresses[CFI_UNLOCK__2AAA]},
{CFI_MFR_SST, 0x00D6, cfi_fixup_0002_unlock_addresses, cfi_unlock_addresses[CFI_UNLOCK__2AAA]},
@@ -90,14 +90,14 @@
};
/* fixup after reading cmdset 0001 primary query table */
-static cfi_fixup_t cfi_0001_fixups[] = {
+static const cfi_fixup_t cfi_0001_fixups[] = {
{0, 0, NULL, NULL}
};
-static void cfi_fixup(flash_bank_t *bank, cfi_fixup_t *fixups)
+static void cfi_fixup(flash_bank_t *bank, const cfi_fixup_t *fixups)
{
cfi_flash_bank_t *cfi_info = bank-driver_priv;
- cfi_fixup_t *f;
+ const cfi_fixup_t *f;
for (f = fixups; f-fixup; f++)
{
Index: src/flash/non_cfi.c
===
--- src/flash/non_cfi.c (revision 2606)
+++ src/flash/non_cfi.c (working copy)
@@ -32,7 +32,7 @@
#define ERASE_REGION(num, size) (((size/256) 16) | (num-1))
/* non-CFI compatible flashes */
-non_cfi_t non_cfi_flashes[] = {
+static non_cfi_t non_cfi_flashes[] = {
{
.mfr = CFI_MFR_SST,
.id = 0xd4,
Index: src/flash/non_cfi.h
===
--- src/flash/non_cfi.h (revision 2606)
+++ src/flash/non_cfi.h (working copy)
@@ -35,7 +35,6 @@
uint8_t status_poll_mask;
} non_cfi_t;
-extern non_cfi_t non_cfi_flashes[];
extern void cfi_fixup_non_cfi(flash_bank_t *bank);
#endif /* NON_CFI_H */
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH: XScale vector table handling / Linux kernel debugging
David Brownell wrote:
That one example shouldn't go *between* the @deffn blocks ...
it's part of the preceding @deffn, giving the bit semantics,
not a free-standing chunk of text.
I must admit I do know nothing about texinfo.
How about this version?
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 the branch destination somewhere in memory. Doing so
+makes sure the code in the vector table stays constant regardless of
+code layout in memory:
+...@example
+_vectors:
+ldr pc,[pc,#0x100-8]
+ldr pc,[pc,#0x100-8]
+ldr pc,[pc,#0x100-8]
+ldr pc,[pc,#0x100-8]
+ldr pc,[pc,#0x100-8]
+ldr pc,[pc,#0x100-8]
+ldr pc,[pc,#0x100-8]
+ldr pc,[pc,#0x100-8]
+.org 0x100
+.long real_reset_vector
+.long
Re: [Openocd-development] small CFI cleanup
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
[Openocd-development] Enhancement proposal: progress output when flashing
Hi all, it would be nice for Openocd to output the progress when flashing a target, something like mplayer does. Two use cases I'm thinking of are command line users, who will see activity report, and other processes (eg. GUIs) which can launch Openocd in background and report progress to the user by parsing Openocd output. What do you think? Best regards, -- Luca Ottaviano lottavi...@develer.com BeRTOS developer - http://dev.bertos.org ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] J-Link Reset Init Issue
Hi Ferdinand, That is indeed what was causing the problem. I didn't notice a change had been made to that particular configuration file. Those files rarely evolve and given that the modification was so subtle, I completely missed it. I am still working through some remaining issues with the reset init command, but at this point I am inclined to believe those are related to configuration issues with the at91sam9g20 processor I am using rather then software bugs in openocd. In any case good catch! Gary :) On 8/24/09 2:48 PM, Ferdinand Postema ferdin...@postema.eu wrote: 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
Re: [Openocd-development] Enhancement proposal: progress output whenflashing
I'm actually doing this in a GUI application. If you set the debug_level to 2 you'll see the progress. -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Luca Ottaviano Sent: dinsdag 25 augustus 2009 10:28 To: openocd-development Subject: [Openocd-development] Enhancement proposal: progress output whenflashing Hi all, it would be nice for Openocd to output the progress when flashing a target, something like mplayer does. Two use cases I'm thinking of are command line users, who will see activity report, and other processes (eg. GUIs) which can launch Openocd in background and report progress to the user by parsing Openocd output. What do you think? Best regards, -- Luca Ottaviano lottavi...@develer.com BeRTOS developer - http://dev.bertos.org ___ 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] J-Link Reset Init Issue
On Tue, Aug 25, 2009 at 3:39 PM, Gary Carlsongcarl...@carlson-minot.com wrote: I am still working through some remaining issues with the reset init command, but at this point I am inclined to believe those are related to configuration issues with the at91sam9g20 processor I am using rather then software bugs in openocd. Or maybe there are some silicon bugs or related issues with the AT91SAM9G20. It seems to be very new. My colleague sitting next to me was evaluating the 9G20, 9260 and 9263 and they seem to have all kinds of problems (even with the original Atmel eval board) -- Xiaofan http://mcuee.blogspot.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
Zach Welch ha scritto: 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. IMO, I think he's frustrated by the number of support requests he gets every day. I admit I asked some questions myself. I can summarize the problems I've had so far with Windows builds of Openocd: 1 - No official exe on the website: building with Cygwin or MinGW under Windows it's *really* a pain. I really appreciate Freddie's work here. This could be easily fixed by providing a Windows build when doing official releases or at least including a Visual Studio project which will build Openocd from sources. 2 - No documentation whatsoever to start using Openocd: when using a jtag interface you need to learn about libusb-win32 drivers, the difference between libusb versions (libusb0.1, libusb1.0, libusb-filters and so on), Vista issues (32-bit differs from 64-bit), jtag composite devices and how they interact with libusb. I understand that all these problems are not Openocd-specific, but indeed they impact Openocd usage. I've seen that this community is by far the largest and most active between the other projects, so I think we are able to at least some basic support. My 2 cents. -- Luca Ottaviano lottavi...@develer.com BeRTOS developer - http://dev.bertos.org ___ 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 5:26 PM, Luca Ottavianolottavi...@develer.com wrote: I can summarize the problems I've had so far with Windows builds of Openocd: 1 - No official exe on the website: building with Cygwin or MinGW under Windows it's *really* a pain. I really appreciate Freddie's work here. I think this is a good idea. Typically a Windows binary is provided for open source projects if Windows is a supported platform. This could be easily fixed by providing a Windows build when doing official releases or at least including a Visual Studio project which will build Openocd from sources. Unfortunately Microsoft's Compiler is not supported right now. So it is not possible to provide a Visual Studio project. So far maybe a build-kit (cygwin+libusb-win32+ libftdi ) is still one of the easier solution. It was discussed before V0.2 release. 2 - No documentation whatsoever to start using Openocd: when using a jtag interface you need to learn about libusb-win32 drivers, the difference between libusb versions (libusb0.1, libusb1.0, libusb-filters and so on), Vista issues (32-bit differs from 64-bit), jtag composite devices and how they interact with libusb. I understand that all these problems are not Openocd-specific, but indeed they impact Openocd usage. I've seen that this community is by far the largest and most active between the other projects, so I think we are able to at least some basic support. I think libusb has rather active community. libusb-win32 mailing list is rather inactive and the project is kind of dormant. libftdi is probably in between and the support of Windows is probably lag behind Linux. -- Xiaofan http://mcuee.blogspot.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
Luca Ottaviano wrote: 2 - No documentation whatsoever to start using Openocd: when using a jtag interface you need to learn about libusb-win32 drivers, the difference between libusb versions (libusb0.1, libusb1.0, libusb-filters and so on), Vista issues (32-bit differs from 64-bit), jtag composite devices and how they interact with libusb. So someone should start writing those documentation, so that it can be included in the OpenOCD manual instead of requiring every user to ask or google for these steps. Simply sitting back and complaining about the lack of documentation won't fix anything. You don't have to be a developer to do that: every user that *has* managed to get it to work should be able to provide some notes on the problems and how he solved them. Others can then build on top of that. However, it is important to submit the documentation so it can be included in the OpenOCD documentation: putting it on some obscure website or forum will not help - it still requires users to gather the needed information from multiple sources, which may not be easy to locate. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] BeagleBoard and Flyswatter
Fred Koehler wrote: 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. Hi Fred, No one is an island. I'm trying to make openOCD work on the beagle recently. By applying the patch your mentioned, I could establish Jtag session (R2606). But it's not enough to me. the support of halt/step/reset operations are out there. :( You can see the the callback function of these commands are NULL. Does anyone know why these commands are NULL? I Followed previous mail list, Magnus Lundin had some contribution on beagle board. https://lists.berlios.de/pipermail/openocd-development/2009-July/009314.html I tried to apply these patch based on R2606, but it still does not work. Have anyone had experience on making openocd work on beagleboard? 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? What are your configs? I did not have this sort of error. Cheers, Matt ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] BeagleBoard and Flyswatter
Did you try with the patches I committed today? -- Ø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 and Flyswatter
On Tue, Aug 25, 2009 at 1:17 PM, Matt Hsum...@0xlab.org wrote: Øyvind Harboe wrote: Did you try with the patches I committed today? Hi Øyvind, Thanks for your reply. Yes. I applied the patch your committed. It definitely works. The jtag session could be established. The problem is I would like to issue commands such as reset halt, bp, resume. The source code shown their implementation are NULL. So I'm curious why coretex_a8 does not have these support? Or why Magnus's patches were not merged? Could you post an updated patch and I'll probably be able to commit it? I'm trying to get some momentum into Cortex A8 development by aggressively committing patches. -- Ø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 and Flyswatter
Øyvind Harboe wrote: Did you try with the patches I committed today? Hi Øyvind, Thanks for your reply. Yes. I applied the patch your committed. It definitely works. The jtag session could be established. The problem is I would like to issue commands such as reset halt, bp, resume. The source code shown their implementation are NULL. So I'm curious why coretex_a8 does not have these support? Or why Magnus's patches were not merged? Cheers, Matt ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] J-Link Reset Init Issue
Hi Gary and Ferdinand, Mea Culpa. I broke the jtag_ntrst_delay in target/at91sam9260.cfg. It worked fine on my target board and the AT91SAM9260-EK. There is something funny with the target reset timing of the different Atmel AT91SAM9xx targets and jtag_ntrst_delay/jtag_nsrst_delay, but I have not worked out what it is yet. Best regards, Pieter Notice This email is intended for the addressee only and may contain legally privileged and/or confidential information. If you have received this email in error and are not the intended recipient, you are hereby informed that you are not entitled to read, broadcast, distribute or in any manner whatsoever use the contents of this email or any attachments thereto. You are requested to please notify Psitek that you have received the email and then delete it. Unless clearly stated otherwise, the content and sentiments expressed in this email or any attachments thereto are those of the sender and not of Psitek (Proprietary) Limited. Psitek does not accept liability for any damages, loss or expense of any nature whatsoever arising (a) out of or in connection with the email or any attachments thereto and/or (b) from any act or omission by the recipient relying upon the content of the email or attachments. Psitek further disclaims liability for any damages caused by computer and/or software viruses. Should this email contain the terms of a contract, no binding agreement will result until such time as a written (hardcopy) document is signed on behalf of Psitek. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] BeagleBoard and Flyswatter
Let's try to organize this a little and summarize the status:
1. Last time I tried was *r2604*:
https://lists.berlios.de/pipermail/openocd-development/2009-August/010035.html
To reproduce this, you have to apply the four patches in attachment of
that mail to r2604.
Fred and Matt: Please try to exactly reproduce this and in case of
differences or other issues, send detailed report.
Matt: As you can see in above mail, halt and resume seem to work there.
2. When we agree on status of (1), then it's time to test recent
trunk. As Øyvind mentioned in
https://lists.berlios.de/pipermail/openocd-development/2009-August/010073.html
he applied 3 of 4 patches from (1) (thanks!). To test this, we have to
apply remaining patch (attachment) and test if result is the same like
in (1). I did so and got the same result as in (1) with *r2619* and
single patch in attachment.
Fred and Matt: Please try to exactly reproduce this and in case of
differences or other issues, send detailed report.
3. When we agree on (1) and (2), the further steps could be:
a) Review/fix/rewrite remaining patch to get it applied. Dave's recent
version of this patch is in
https://lists.berlios.de/pipermail/openocd-development/2009-August/010041.html
btw (see attachment, too).
b) Fix the issues mentioned in (1):
- Fix OLD SYNTAX: DEPRECATED - use jtag_khz, not jtag_speed
- Fix invalid mode value encountered warnings
- Fix soft_reset_halt segfault
- Update eLinux OpenOCD Beagle page
- ...
Best regards
Dirk
Matt Hsu wrote:
Øyvind Harboe wrote:
Did you try with the patches I committed today?
Hi Øyvind,
Thanks for your reply.
Yes. I applied the patch your committed. It definitely works.
The jtag session could be established.
The problem is I would like to issue commands such as reset halt,
bp, resume.
The source code shown their implementation are NULL.
So I'm curious why coretex_a8 does not have these support?
Or why Magnus's patches were not merged?
Cheers,
Matt
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
---
src/jtag/core.c |8
1 file changed, 8 insertions(+)
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -469,6 +469,14 @@ void jtag_add_tlr(void)
{
jtag_prelude(TAP_RESET);
jtag_set_error(interface_jtag_add_tlr());
+
+ /*
+* Add a bunch of clocks after TLR entry to force SWD reset (newer
+* ARM cores; just in case, ~50 cycles), switch on ICEpick power
+* domains (for some TI parts, ~100 cycles), etc
+*/
+ jtag_set_error(interface_jtag_add_runtest(100, TAP_RESET));
+
jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + beagle
Øyvind Harboe wrote:
I have committed all but 01_openocd_beagle.patch to hopefully get things
moving along
01_openocd_beagle.patch is problematic because it modifies the behavior
for *all* targets.
Thoughts?
You might have noticed that I'm not really an expert of OpenOCD's code ;)
Is anything like
if(omap3) {
/*
* Add a bunch of clocks after TLR entry to force SWD reset (newer
* ARM cores; just in case, ~50 cycles), switch on ICEpick power
* domains (for some TI parts, ~100 cycles), etc
*/
jtag_set_error(interface_jtag_add_runtest(100, TAP_RESET));
}
possible? Or, probably better, enable/configure this by an external
configuration (TCL?) variable/parameter?
Best regards
Dirk
___
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
Rohit Chandel pisze: It might seem silly question for an experienced person but please excuse for this. Does that mean that I need to first install the the drivers which came along with the ARM-USB-TINY on a CD and then uninstall the driver for JTAG. And then install libusb-win32 for JTAG alone? In your earlier post you provided a link to .pdf for the JTAG with RS-232. Now I know that you version (-TINY) doesn't have that interface. You should do exactly as it's said in the .inf file for OpenOCD: ; Devices which use only the first channel (JTAG only) should have TWO entries ; for BOTH channels. Amontec JTAGkey is an example. ... Amontec JTAGkey (Channel A)=LIBUSB_DEV, USB\VID_0403PID_cff8MI_00 Amontec JTAGkey (Channel B)=LIBUSB_DEV, USB\VID_0403PID_cff8MI_01 Do the same for your JTAG and the drivers part will be done. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + beagle
On Tue, Aug 25, 2009 at 4:33 PM, Dirk Behmedirk.be...@googlemail.com wrote:
Øyvind Harboe wrote:
I have committed all but 01_openocd_beagle.patch to hopefully get things
moving along
01_openocd_beagle.patch is problematic because it modifies the behavior
for *all* targets.
Thoughts?
You might have noticed that I'm not really an expert of OpenOCD's code ;)
Is anything like
if(omap3) {
/*
* Add a bunch of clocks after TLR entry to force SWD reset (newer
* ARM cores; just in case, ~50 cycles), switch on ICEpick power
* domains (for some TI parts, ~100 cycles), etc
*/
jtag_set_error(interface_jtag_add_runtest(100, TAP_RESET));
}
possible? Or, probably better, enable/configure this by an external
configuration (TCL?) variable/parameter?
We need some more general mechanism. OpenOCD shouldn't
litter it's lower layers w/target specific hacks.
--
Ø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 0.2.0 : Olimex ARM-USB-TINY - unable to find driver software
Ok, I did it... but how do i make sure that drivers have installed correctly? I used FTClean.exe to remove all FTDI drivers and then installed the new ones. In Device manager under LibUSB-Win32 Devices I have got an entry for Olimex OpenOCD JTAG TINY A. Also in driver Properties- Driver details it shows driver files: C:\Windows\system32\drivers\libusb0.sys C:\Windows\system32\drivers\libusb0.dll Is there any quick test to find out that openocd is installed correctly? regards rohit On Tue, Aug 25, 2009 at 9:41 PM, Freddie Chopin freddie_cho...@op.plwrote: Rohit Chandel pisze: It might seem silly question for an experienced person but please excuse for this. Does that mean that I need to first install the the drivers which came along with the ARM-USB-TINY on a CD and then uninstall the driver for JTAG. And then install libusb-win32 for JTAG alone? In your earlier post you provided a link to .pdf for the JTAG with RS-232. Now I know that you version (-TINY) doesn't have that interface. You should do exactly as it's said in the .inf file for OpenOCD: ; Devices which use only the first channel (JTAG only) should have TWO entries ; for BOTH channels. Amontec JTAGkey is an example. ... Amontec JTAGkey (Channel A)=LIBUSB_DEV, USB\VID_0403PID_cff8MI_00 Amontec JTAGkey (Channel B)=LIBUSB_DEV, USB\VID_0403PID_cff8MI_01 Do the same for your JTAG and the drivers part will be done. 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
On Tuesday 25 August 2009, Michael Schwingen wrote: Luca Ottaviano wrote: 2 - No documentation whatsoever to start using Openocd: when using a jtag interface you need to learn about libusb-win32 drivers, the difference between libusb versions (libusb0.1, libusb1.0, libusb-filters and so on), Vista issues (32-bit differs from 64-bit), jtag composite devices and how they interact with libusb. So someone should start writing those documentation, so that it can be included in the OpenOCD manual instead of requiring every user to ask or google for these steps. Yep; though I think such builder docs should not be part of the user's guide (openocd.texi) or of the developer's manual (doxygen stuff). Windows based distros should eventually avoid a lot of that once they sort out the build probs for libftdi... Simply sitting back and complaining about the lack of documentation won't fix anything. You don't have to be a developer to do that: every user that *has* managed to get it to work should be able to provide some notes on the problems and how he solved them. Others can then build on top of that. However, it is important to submit the documentation so it can be included in the OpenOCD documentation: putting it on some obscure website or forum will not help - it still requires users to gather the needed information from multiple sources, which may not be easy to locate. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH: XScale vector table handling / Linux kernel debugging
On Tuesday 25 August 2009, Michael Schwingen wrote: That one example shouldn't go *between* the @deffn blocks ... it's part of the preceding @deffn, giving the bit semantics, not a free-standing chunk of text. I must admit I do know nothing about texinfo. How about this version? OK; thanks! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] BeagleBoard and Flyswatter
On Tuesday 25 August 2009, Dirk Behme wrote: - Fix soft_reset_halt segfault Patch in the works ... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] BeagleBoard and Flyswatter
David Brownell wrote: On Tuesday 25 August 2009, Matt Hsu wrote: The problem is I would like to issue commands such as reset halt, bp, resume. The source code shown their implementation are NULL. So I'm curious why coretex_a8 does not have these support? Because nobody submitted patches implementing them yet.. Join in! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development That is weird ! The halt, step, resume and bp handling should be there. The patches and files that was submitted to the list 07/08/2009 (with copies to Dirk) contains cortex_a8.c/h with working halt/step/resume/bp implementations. Of course there might be bugs but they were tested on my Flyswatter/Begle system. I also had no special problems with invalid mode value encountered when debugging UBoot or code loaded into RAM after starting up the Beagleboard to UBoot. No reset functions were implemented. My suggestion was to make a complete replacement of the old cortex_a8 files with the new ones, commit this, test and only then then do the cleanups and larger rewrites. The old code never worked and is not worth preserving, not even as a baseline. Happy hacking, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] J-Link Reset Init Issue
No worry's mate! Ferdinand Pieter Conradie wrote: Hi Gary and Ferdinand, Mea Culpa. I broke the jtag_ntrst_delay in target/at91sam9260.cfg. It worked fine on my target board and the AT91SAM9260-EK. There is something funny with the target reset timing of the different Atmel AT91SAM9xx targets and jtag_ntrst_delay/jtag_nsrst_delay, but I have not worked out what it is yet. Best regards, Pieter Notice This email is intended for the addressee only and may contain legally privileged and/or confidential information. If you have received this email in error and are not the intended recipient, you are hereby informed that you are not entitled to read, broadcast, distribute or in any manner whatsoever use the contents of this email or any attachments thereto. You are requested to please notify Psitek that you have received the email and then delete it. Unless clearly stated otherwise, the content and sentiments expressed in this email or any attachments thereto are those of the sender and not of Psitek (Proprietary) Limited. Psitek does not accept liability for any damages, loss or expense of any nature whatsoever arising (a) out of or in connection with the email or any attachments thereto and/or (b) from any act or omission by the recipient relying upon the content of the email or attachments. Psitek further disclaims liability for any damages caused by computer and/or software viruses. Should this email contain the terms of a contract, no binding agreement will result until such time as a written (hardcopy) document is signed on behalf of Psitek. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + beagle
On Tuesday 25 August 2009, Øyvind Harboe wrote:
01_openocd_beagle.patch is problematic because it modifies the behavior
for *all* targets.
Thoughts?
I see no problem ... TAP_RESET is a stable state, and
JTAG adapters are allowed to let TCK run freely there.
We need some more general mechanism. OpenOCD shouldn't
litter it's lower layers w/target specific hacks.
I'd agree if we had any evidence that this could cause
trouble ... equally, we don't want to clutter things
with special cases that can interact poorly.
Note that some PXAs wanted extra TCK cycles too.
- Dave
=== CUT HERE
Partial fix for TAPs which need extra TCK cycles in the TAP_RESET
state. This relies on the fact that TAP_RESET is a stable state,
where TCK may run freely, and always issues those TCK cycles.
This doesn't address entry to TAP_RESET using TRST. Fixing that
will require calling jtag_add_tlr() after deasserting TRST.
---
src/jtag/core.c |9 +
1 file changed, 9 insertions(+)
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -469,6 +469,15 @@ void jtag_add_tlr(void)
{
jtag_prelude(TAP_RESET);
jtag_set_error(interface_jtag_add_tlr());
+
+ /*
+* Add a bunch of clocks after TLR entry to force SWD reset (newer
+* ARM cores; just in case, ~50 cycles), switch on ICEpick power
+* domains (for some TI parts, ~100 cycles), etc. TAP_RESET is a
+* stable state, so this must be harmless to all JTAG controllers.
+*/
+ jtag_set_error(interface_jtag_add_runtest(100, TAP_RESET));
+
jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
}
Partial fix for TAPs which need extra TCK cycles in the TAP_RESET
state. This relies on the fact that TAP_RESET is a stable state,
where TCK may run freely, and always issues those TCK cycles.
This doesn't address entry to TAP_RESET using TRST. Fixing that
will require calling jtag_add_tlr() after deasserting TRST.
---
src/jtag/core.c |9 +
1 file changed, 9 insertions(+)
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -469,6 +469,15 @@ void jtag_add_tlr(void)
{
jtag_prelude(TAP_RESET);
jtag_set_error(interface_jtag_add_tlr());
+
+ /*
+ * Add a bunch of clocks after TLR entry to force SWD reset (newer
+ * ARM cores; just in case, ~50 cycles), switch on ICEpick power
+ * domains (for some TI parts, ~100 cycles), etc. TAP_RESET is a
+ * stable state, so this must be harmless to all JTAG controllers.
+ */
+ jtag_set_error(interface_jtag_add_runtest(100, TAP_RESET));
+
jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] don't segv certain calls
Accomodate targets which don't support various target-specific
reset operations. Maybe they can't; or it's a not yet thing.
Note that the assert/deassert operations can't yet trigger for
OMAP3 because resets currently include JTAG reset in all cases,
resetting the ICEpick and thus disabling the TAP for Cortex-A8.
---
src/target/target.c | 12
1 file changed, 12 insertions(+)
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -559,6 +559,11 @@ static int target_soft_reset_halt_imp(st
LOG_ERROR(Target not examined yet);
return ERROR_FAIL;
}
+ if (!target-type-soft_reset_halt_imp) {
+ LOG_ERROR(Target %s does not support soft_reset_halt,
+ target-cmd_name);
+ return ERROR_FAIL;
+ }
return target-type-soft_reset_halt_imp(target);
}
@@ -4035,6 +4040,13 @@ static int tcl_target_func(Jim_Interp *i
}
if (!target-tap-enabled)
goto err_tap_disabled;
+ if (!target-type-assert_reset
+ || !target-type-deassert_reset) {
+ Jim_SetResult_sprintf(interp,
+ No target-specific reset for %s,
+ target-cmd_name);
+ return JIM_ERR;
+ }
/* determine if we should halt or not. */
target-reset_halt = !!a;
/* When this happens - all workareas are invalid. */
Accomodate targets which don't support various target-specific
reset operations. Maybe they can't; or it's a not yet thing.
Note that the assert/deassert operations can't yet trigger for
OMAP3 because resets currently include JTAG reset in all cases,
resetting the ICEpick and thus disabling the TAP for Cortex-A8.
---
src/target/target.c | 12
1 file changed, 12 insertions(+)
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -559,6 +559,11 @@ static int target_soft_reset_halt_imp(st
LOG_ERROR(Target not examined yet);
return ERROR_FAIL;
}
+ if (!target-type-soft_reset_halt_imp) {
+ LOG_ERROR(Target %s does not support soft_reset_halt,
+target-cmd_name);
+ return ERROR_FAIL;
+ }
return target-type-soft_reset_halt_imp(target);
}
@@ -4035,6 +4040,13 @@ static int tcl_target_func(Jim_Interp *i
}
if (!target-tap-enabled)
goto err_tap_disabled;
+ if (!target-type-assert_reset
+|| !target-type-deassert_reset) {
+ Jim_SetResult_sprintf(interp,
+ No target-specific reset for %s,
+ target-cmd_name);
+ return JIM_ERR;
+ }
/* determine if we should halt or not. */
target-reset_halt = !!a;
/* When this happens - all workareas are invalid. */
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch 2/3] add_reset cleanup: TAP_RESET unification
More jtag_add_reset() cleanup:
Unify the handling of the req_tlr_or_trst parameter. Basically,
JTAG TMS+TCK ops (TLR) is always used ... unless TRST is a safe
option in this system configuration.
---
src/jtag/core.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -597,6 +597,23 @@ void jtag_add_reset(int req_tlr_or_trst,
int new_srst;
int new_trst = 0;
+ /* JTAG reset (entry to TAP_RESET state) can always be achieved
+* using TCK and TMS; that may go through a TAP_{IR,DR}UPDATE
+* state first. TRST accelerates it, and bypasses those states.
+*
+* RESET_TRST_PULLS_SRST is a board or chip level quirk, which
+* can kick in even if the JTAG adapter can't drive SRST.
+*/
+ if (req_tlr_or_trst) {
+ if (!(jtag_reset_config RESET_HAS_TRST))
+ trst_with_tlr = 1;
+ else if ((jtag_reset_config RESET_TRST_PULLS_SRST) != 0
+!req_srst)
+ trst_with_tlr = 1;
+ else
+ new_trst = 1;
+ }
+
/* FIX!!! there are *many* different cases here. A better
* approach is needed for legal combinations of transitions...
*/
@@ -623,12 +640,6 @@ void jtag_add_reset(int req_tlr_or_trst,
return;
}
- /* if TRST pulls SRST, we reset with TAP T-L-R */
- if (((jtag_reset_config RESET_TRST_PULLS_SRST) (req_tlr_or_trst))
(req_srst == 0))
- {
- trst_with_tlr = 1;
- }
-
if (req_srst !(jtag_reset_config RESET_HAS_SRST))
{
LOG_ERROR(BUG: requested SRST assertion, but the current
configuration doesn't support this);
@@ -636,17 +647,6 @@ void jtag_add_reset(int req_tlr_or_trst,
return;
}
- if (req_tlr_or_trst)
- {
- if (!trst_with_tlr (jtag_reset_config RESET_HAS_TRST))
- {
- new_trst = 1;
- } else
- {
- trst_with_tlr = 1;
- }
- }
-
new_srst = req_srst;
/* Maybe change TRST and/or SRST signal state */
@@ -840,6 +840,7 @@ static int jtag_reset_callback(enum jtag
{
tap-enabled = !tap-disabled_after_reset;
+ /* current instruction is either BYPASS or IDCODE */
buf_set_ones(tap-cur_instr, tap-ir_length);
tap-bypass = 1;
}
More jtag_add_reset() cleanup:
Unify the handling of the req_tlr_or_trst parameter. Basically,
JTAG TMS+TCK ops (TLR) is always used ... unless TRST is a safe
option in this system configuration.
---
src/jtag/core.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -597,6 +597,23 @@ void jtag_add_reset(int req_tlr_or_trst,
int new_srst;
int new_trst = 0;
+ /* JTAG reset (entry to TAP_RESET state) can always be achieved
+ * using TCK and TMS; that may go through a TAP_{IR,DR}UPDATE
+ * state first. TRST accelerates it, and bypasses those states.
+ *
+ * RESET_TRST_PULLS_SRST is a board or chip level quirk, which
+ * can kick in even if the JTAG adapter can't drive SRST.
+ */
+ if (req_tlr_or_trst) {
+ if (!(jtag_reset_config RESET_HAS_TRST))
+ trst_with_tlr = 1;
+ else if ((jtag_reset_config RESET_TRST_PULLS_SRST) != 0
+ !req_srst)
+ trst_with_tlr = 1;
+ else
+ new_trst = 1;
+ }
+
/* FIX!!! there are *many* different cases here. A better
* approach is needed for legal combinations of transitions...
*/
@@ -623,12 +640,6 @@ void jtag_add_reset(int req_tlr_or_trst,
return;
}
- /* if TRST pulls SRST, we reset with TAP T-L-R */
- if (((jtag_reset_config RESET_TRST_PULLS_SRST) (req_tlr_or_trst)) (req_srst == 0))
- {
- trst_with_tlr = 1;
- }
-
if (req_srst !(jtag_reset_config RESET_HAS_SRST))
{
LOG_ERROR(BUG: requested SRST assertion, but the current configuration doesn't support this);
@@ -636,17 +647,6 @@ void jtag_add_reset(int req_tlr_or_trst,
return;
}
- if (req_tlr_or_trst)
- {
- if (!trst_with_tlr (jtag_reset_config RESET_HAS_TRST))
- {
- new_trst = 1;
- } else
- {
- trst_with_tlr = 1;
- }
- }
-
new_srst = req_srst;
/* Maybe change TRST and/or SRST signal state */
@@ -840,6 +840,7 @@ static int jtag_reset_callback(enum jtag
{
tap-enabled = !tap-disabled_after_reset;
+ /* current instruction is either BYPASS or IDCODE */
buf_set_ones(tap-cur_instr, tap-ir_length);
tap-bypass = 1;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch 1/3] add_reset cleanup: shrink work
Some jtag_add_reset() cleanup:
- Track whether TRST and/or SRST actually change:
* If they're not changing, don't ask the JTAG adapter to do anything!
(JTAG TCK/TMS ops might still be used to enter TAP_RESET though.)
* Don't change their recorded values until after the adapter says it
did so ... so fault paths can't leave corrupt state.
* Detect and report jtag_execute_queue() failure mode
* Only emit messages saying what really changed; this includes adding
an omitted deasserted TRST message.
* Only apply delays after deasserting SRST/TRST if we *DID* deassert!
- Messages say TLR not RESET, to be less confusing; there are many
kinds of reset. (Though TLR isn't quite ideal either, since it's
the name of the TAP state being entered by TMS+TCK or TRST; it's at
least non-ambiguous in context.)
So the main effect is to do only the work this routine was told to do;
and to have debug messaging make more sense.
---
src/jtag/core.c | 104 --
1 file changed, 62 insertions(+), 42 deletions(-)
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -60,11 +60,15 @@ static int jtag_error = ERROR_OK;
static const char *jtag_event_strings[] =
{
- [JTAG_TRST_ASSERTED] = JTAG controller reset (RESET or TRST),
+ [JTAG_TRST_ASSERTED] = JTAG controller reset (TLR or TRST),
[JTAG_TAP_EVENT_ENABLE] = TAP enabled,
[JTAG_TAP_EVENT_DISABLE] = TAP disabled,
};
+/*
+ * JTAG adapters must initialize with TRST and SRST de-asserted
+ * (they're negative logic, so that means *high*)
+ */
static int jtag_trst = 0;
static int jtag_srst = 0;
@@ -590,6 +594,8 @@ void jtag_add_clocks(int num_cycles)
void jtag_add_reset(int req_tlr_or_trst, int req_srst)
{
int trst_with_tlr = 0;
+ int new_srst;
+ int new_trst = 0;
/* FIX!!! there are *many* different cases here. A better
* approach is needed for legal combinations of transitions...
@@ -634,58 +640,72 @@ void jtag_add_reset(int req_tlr_or_trst,
{
if (!trst_with_tlr (jtag_reset_config RESET_HAS_TRST))
{
- jtag_trst = 1;
+ new_trst = 1;
} else
{
trst_with_tlr = 1;
}
- } else
- {
- jtag_trst = 0;
}
- jtag_srst = req_srst;
+ new_srst = req_srst;
- int retval = interface_jtag_add_reset(jtag_trst, jtag_srst);
- if (retval != ERROR_OK)
- {
- jtag_set_error(retval);
- return;
- }
- jtag_execute_queue();
+ /* Maybe change TRST and/or SRST signal state */
+ if (jtag_srst != new_srst || jtag_trst != new_trst) {
+ int retval;
- if (jtag_srst)
- {
- LOG_DEBUG(SRST line asserted);
+ retval = interface_jtag_add_reset(new_trst, new_srst);
+ if (retval != ERROR_OK)
+ jtag_set_error(retval);
+ else
+ retval = jtag_execute_queue();
+
+ if (retval != ERROR_OK) {
+ LOG_ERROR(TRST/SRST error %d, retval);
+ return;
+ }
}
- else
- {
- LOG_DEBUG(SRST line released);
- if (jtag_nsrst_delay)
- jtag_add_sleep(jtag_nsrst_delay * 1000);
+
+ /* SRST resets everything hooked up to that signal */
+ if (jtag_srst != new_srst) {
+ jtag_srst = new_srst;
+ if (jtag_srst)
+ LOG_DEBUG(SRST line asserted);
+ else {
+ LOG_DEBUG(SRST line released);
+ if (jtag_nsrst_delay)
+ jtag_add_sleep(jtag_nsrst_delay * 1000);
+ }
}
- if (trst_with_tlr)
- {
- LOG_DEBUG(JTAG reset with RESET instead of TRST);
+ /* Maybe enter the JTAG TAP_RESET state ...
+* - using only TMS, TCK, and the JTAG state machine
+* - or else more directly, using TRST
+*
+* TAP_RESET should be invisible to non-debug parts of the system.
+*/
+ if (trst_with_tlr) {
+ LOG_DEBUG(JTAG reset with TLR instead of TRST);
jtag_set_end_state(TAP_RESET);
jtag_add_tlr();
- return;
- }
- if (jtag_trst)
- {
- /* we just asserted nTRST, so we're now in Test-Logic-Reset,
-* and inform possible listeners about this
-*/
- LOG_DEBUG(TRST line asserted);
- tap_set_state(TAP_RESET);
- jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
- }
- else
- {
- if (jtag_ntrst_delay)
- jtag_add_sleep(jtag_ntrst_delay *
[Openocd-development] [patch] tweak ARM disassembly
Tweak disassembly commands:
For ARMv4/ARMv5:
- better command parameter error checking
- don't require an instruction count; default to one
- recognize thumb function addresses
- make function static
- shorten some too-long lines
For Cortex-M3:
- don't require an instruction count; default to one
With the relevant doc updates.
---
Nyet done: invoke the thumb2 disassembler on v4/v5,
to better handle branch instructions.
doc/openocd.texi |9 +--
src/target/armv4_5.c | 55 +--
src/target/cortex_m3.c | 28 +--
3 files changed, 61 insertions(+), 31 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -4612,10 +4612,12 @@ The target may later be resumed in the c
that is not currently supported in OpenOCD.)
@end deffn
-...@deffn Command {armv4_5 disassemble} address count [thumb]
+...@deffn Command {armv4_5 disassemble} address [count [...@option{thumb}]]
@cindex disassemble
Disassembles @var{count} instructions starting at @var{address}.
-If @option{thumb} is specified, Thumb (16-bit) instructions are used;
+If @var{count} is not specified, a single instruction is disassembled.
+If @option{thumb} is specified, or the low bit of the address is set,
+Thumb (16-bit) instructions are used;
else ARM (32-bit) instructions are used.
(Processors may also support the Jazelle state, but
those instructions are not currently understood by OpenOCD.)
@@ -5086,9 +5088,10 @@ If @var{value} is defined, first assigns
@subsection Cortex-M3 specific commands
@cindex Cortex-M3
-...@deffn Command {cortex_m3 disassemble} address count
+...@deffn Command {cortex_m3 disassemble} address [count]
@cindex disassemble
Disassembles @var{count} Thumb2 instructions starting at @var{address}.
+If @var{count} is not specified, a single instruction is disassembled.
@end deffn
@deffn Command {cortex_m3 maskisr} (@option{on}|@option{off})
--- a/src/target/armv4_5.c
+++ b/src/target/armv4_5.c
@@ -387,13 +387,15 @@ int handle_armv4_5_core_state_command(st
return ERROR_OK;
}
-int handle_armv4_5_disassemble_command(struct command_context_s *cmd_ctx, char
*cmd, char **args, int argc)
+static int
+handle_armv4_5_disassemble_command(struct command_context_s *cmd_ctx,
+ char *cmd, char **args, int argc)
{
int retval = ERROR_OK;
target_t *target = get_current_target(cmd_ctx);
armv4_5_common_t *armv4_5 = target-arch_info;
uint32_t address;
- int count;
+ int count = 1;
int i;
arm_instruction_t cur_instruction;
uint32_t opcode;
@@ -406,19 +408,32 @@ int handle_armv4_5_disassemble_command(s
return ERROR_OK;
}
- if (argc 2)
- {
- command_print(cmd_ctx, usage: armv4_5 disassemble address
count ['thumb']);
+ switch (argc) {
+ case 3:
+ if (strcmp(args[2], thumb) != 0)
+ goto usage;
+ thumb = 1;
+ /* FALL THROUGH */
+ case 2:
+ count = strtoul(args[1], NULL, 0);
+ /* FALL THROUGH */
+ case 1:
+ address = strtoul(args[0], NULL, 0);
+ if (address 0x01) {
+ if (!thumb) {
+ command_print(cmd_ctx, Disassemble as Thumb);
+ thumb = 1;
+ }
+ address = ~1;
+ }
+ break;
+ default:
+usage:
+ command_print(cmd_ctx,
+ usage: armv4_5 disassemble address [count
['thumb']]);
return ERROR_OK;
}
- address = strtoul(args[0], NULL, 0);
- count = strtoul(args[1], NULL, 0);
-
- if (argc = 3)
- if (strcmp(args[2], thumb) == 0)
- thumb = 1;
-
for (i = 0; i count; i++)
{
if (thumb)
@@ -453,12 +468,20 @@ int armv4_5_register_commands(struct com
{
command_t *armv4_5_cmd;
- armv4_5_cmd = register_command(cmd_ctx, NULL, armv4_5, NULL,
COMMAND_ANY, armv4/5 specific commands);
+ armv4_5_cmd = register_command(cmd_ctx, NULL, armv4_5,
+ NULL, COMMAND_ANY,
+ armv4/5 specific commands);
- register_command(cmd_ctx, armv4_5_cmd, reg,
handle_armv4_5_reg_command, COMMAND_EXEC, display ARM core registers);
- register_command(cmd_ctx, armv4_5_cmd, core_state,
handle_armv4_5_core_state_command, COMMAND_EXEC, display/change ARM core state
arm | thumb);
+ register_command(cmd_ctx, armv4_5_cmd, reg,
+ handle_armv4_5_reg_command, COMMAND_EXEC,
+ display ARM core registers);
+ register_command(cmd_ctx, armv4_5_cmd, core_state,
+ handle_armv4_5_core_state_command, COMMAND_EXEC,
+ display/change ARM core
[Openocd-development] [patch] NEWS updates for 0.3.0
Various updates to 0.3.0 NEWS --- NEWS | 25 + 1 file changed, 21 insertions(+), 4 deletions(-) --- a/NEWS +++ b/NEWS @@ -1,13 +1,30 @@ -This file should include items worth mentioning in the -OpenOCD openocd-0.2.0 source archive release. - -The following areas of OpenOCD functionality changed in this release: +This file should include highlights of the changes made in the +OpenOCD openocd-0.3.0 source archive release. See the repository +history for details about what changed, including bugfixes and +other issues not mentioned here. JTAG Layer: +FT2232H (high speed USB) support doesn't need separate configuration + Target Layer: +New commands for use with Cortex-M3 processors: + cortex_m3 disassemble ... Thumb2 disassembly (UAL format) + cortex_m3 vector_catch ... traps certain hardware faults + without tying up breakpoint resources +If you're willing to help debug it: VERY EARLY Cortex-A8 support + Flash Layer: +The lpc2000 driver handles the new NXP LPC1700 (Cortex-M3) chips + Board, Target, and Interface Configuration Scripts: +Cleanup and additions for the TI/Luminary Stellaris scripts +LPC1768 target (and flash) support + Keil MCB1700 eval board +Samsung s3c2450 + Mini2440 board + Documentation: + Build and Release: For more details about what has changed since the last release, Various updates to 0.3.0 NEWS --- NEWS | 25 + 1 file changed, 21 insertions(+), 4 deletions(-) --- a/NEWS +++ b/NEWS @@ -1,13 +1,30 @@ -This file should include items worth mentioning in the -OpenOCD openocd-0.2.0 source archive release. - -The following areas of OpenOCD functionality changed in this release: +This file should include highlights of the changes made in the +OpenOCD openocd-0.3.0 source archive release. See the repository +history for details about what changed, including bugfixes and +other issues not mentioned here. JTAG Layer: +FT2232H (high speed USB) support doesn't need separate configuration + Target Layer: +New commands for use with Cortex-M3 processors: + cortex_m3 disassemble ... Thumb2 disassembly (UAL format) + cortex_m3 vector_catch ... traps certain hardware faults + without tying up breakpoint resources +If you're willing to help debug it: VERY EARLY Cortex-A8 support + Flash Layer: +The lpc2000 driver handles the new NXP LPC1700 (Cortex-M3) chips + Board, Target, and Interface Configuration Scripts: +Cleanup and additions for the TI/Luminary Stellaris scripts +LPC1768 target (and flash) support + Keil MCB1700 eval board +Samsung s3c2450 + Mini2440 board + Documentation: + Build and Release: For more details about what has changed since the last release, ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + beagle
On Friday 21 August 2009, Dirk Behme wrote: While reading in the git thread the keyword branch: What's about a beagle-testing or similar branch with the patches mentioned above? Feel free to set up such a GIT branch in a repository you create ... :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch 3/3] add_reset cleanup: SRST unification
More jtag_add_reset() cleanup:
Unify the handling of the req_srst parameter, and rip out a
large NOP branch and its associated FIXME. (There didn't seem
to be anything that needs fixing; but that was unclear since
the constraints were scattered all over the place not unified.)
---
src/jtag/core.c | 59 +-
1 file changed, 23 insertions(+), 36 deletions(-)
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -594,9 +594,31 @@ void jtag_add_clocks(int num_cycles)
void jtag_add_reset(int req_tlr_or_trst, int req_srst)
{
int trst_with_tlr = 0;
- int new_srst;
+ int new_srst = 0;
int new_trst = 0;
+ /* Without SRST, we must use target-specific JTAG operations
+* on each target; callers should not be requesting SRST when
+* that signal doesn't exist.
+*
+* RESET_SRST_PULLS_TRST is a board or chip level quirk, which
+* can kick in even if the JTAG adapter can't drive TRST.
+*/
+ if (req_srst) {
+ if (!(jtag_reset_config RESET_HAS_SRST)) {
+ LOG_ERROR(BUG: can't assert SRST);
+ jtag_set_error(ERROR_FAIL);
+ return;
+ }
+ if ((jtag_reset_config RESET_SRST_PULLS_TRST) != 0
+!req_tlr_or_trst) {
+ LOG_ERROR(BUG: can't assert only SRST);
+ jtag_set_error(ERROR_FAIL);
+ return;
+ }
+ new_srst = 1;
+ }
+
/* JTAG reset (entry to TAP_RESET state) can always be achieved
* using TCK and TMS; that may go through a TAP_{IR,DR}UPDATE
* state first. TRST accelerates it, and bypasses those states.
@@ -614,41 +636,6 @@ void jtag_add_reset(int req_tlr_or_trst,
new_trst = 1;
}
- /* FIX!!! there are *many* different cases here. A better
-* approach is needed for legal combinations of transitions...
-*/
- if ((jtag_reset_config RESET_HAS_SRST)
- (jtag_reset_config RESET_HAS_TRST)
- ((jtag_reset_config RESET_SRST_PULLS_TRST) == 0))
- {
- if (((req_tlr_or_trst!jtag_trst)||
- (!req_tlr_or_trst jtag_trst))
- ((req_srst!jtag_srst)||
- (!req_srst jtag_srst)))
- {
- /* FIX!!! srst_pulls_trst allows 1,1 = 0,0
transition */
- //LOG_ERROR(BUG: transition of req_tlr_or_trst and
req_srst in the same jtag_add_reset() call is undefined);
- }
- }
-
- /* Make sure that jtag_reset_config allows the requested reset */
- /* if SRST pulls TRST, we can't fulfill srst == 1 with trst == 0 */
- if (((jtag_reset_config RESET_SRST_PULLS_TRST) (req_srst == 1))
(!req_tlr_or_trst))
- {
- LOG_ERROR(BUG: requested reset would assert trst);
- jtag_set_error(ERROR_FAIL);
- return;
- }
-
- if (req_srst !(jtag_reset_config RESET_HAS_SRST))
- {
- LOG_ERROR(BUG: requested SRST assertion, but the current
configuration doesn't support this);
- jtag_set_error(ERROR_FAIL);
- return;
- }
-
- new_srst = req_srst;
-
/* Maybe change TRST and/or SRST signal state */
if (jtag_srst != new_srst || jtag_trst != new_trst) {
int retval;
More jtag_add_reset() cleanup:
Unify the handling of the req_srst parameter, and rip out a
large NOP branch and its associated FIXME. (There didn't seem
to be anything that needs fixing; but that was unclear since
the constraints were scattered all over the place not unified.)
---
src/jtag/core.c | 59 +-
1 file changed, 23 insertions(+), 36 deletions(-)
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -594,9 +594,31 @@ void jtag_add_clocks(int num_cycles)
void jtag_add_reset(int req_tlr_or_trst, int req_srst)
{
int trst_with_tlr = 0;
- int new_srst;
+ int new_srst = 0;
int new_trst = 0;
+ /* Without SRST, we must use target-specific JTAG operations
+ * on each target; callers should not be requesting SRST when
+ * that signal doesn't exist.
+ *
+ * RESET_SRST_PULLS_TRST is a board or chip level quirk, which
+ * can kick in even if the JTAG adapter can't drive TRST.
+ */
+ if (req_srst) {
+ if (!(jtag_reset_config RESET_HAS_SRST)) {
+ LOG_ERROR(BUG: can't assert SRST);
+ jtag_set_error(ERROR_FAIL);
+ return;
+ }
+ if ((jtag_reset_config RESET_SRST_PULLS_TRST) != 0
+ !req_tlr_or_trst) {
+ LOG_ERROR(BUG: can't assert only SRST);
+ jtag_set_error(ERROR_FAIL);
+ return;
+ }
+ new_srst = 1;
+ }
+
/* JTAG reset (entry to TAP_RESET state) can always be achieved
* using
Re: [Openocd-development] OpenOCD + beagle
David Brownell wrote: On Friday 21 August 2009, Dirk Behme wrote: While reading in the git thread the keyword branch: What's about a beagle-testing or similar branch with the patches mentioned above? Feel free to set up such a GIT branch in a repository you create ... :) With patches applied today and your updates (which will be applied hopefully soon, too) this isn't necessary any more ;) Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + beagle
I see no problem ... TAP_RESET is a stable state, and
JTAG adapters are allowed to let TCK run freely there.
But that's not what the code is doing. It goes to TAP_RESET,
then cycles 100 times in runtest idle and then back to TAP_RESET
I guess I would be more comfortable with a change that cycled
100 clocks in reset that's probably harmless everywhere and
would let us invent a more generic scheme in time if it ever proved
necessary.
(non-sequitor: can we break out new discussion threads
a bit more often... easier to track residual issues)
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
Partial fix for TAPs which need extra TCK cycles in the TAP_RESET
state. This relies on the fact that TAP_RESET is a stable state,
where TCK may run freely, and always issues those TCK cycles.
This doesn't address entry to TAP_RESET using TRST. Fixing that
will require calling jtag_add_tlr() after deasserting TRST.
---
src/jtag/core.c |9 +
1 file changed, 9 insertions(+)
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -469,6 +469,15 @@ void jtag_add_tlr(void)
{
jtag_prelude(TAP_RESET);
jtag_set_error(interface_jtag_add_tlr());
+
+ /*
+ * Add a bunch of clocks after TLR entry to force SWD reset (newer
+ * ARM cores; just in case, ~50 cycles), switch on ICEpick power
+ * domains (for some TI parts, ~100 cycles), etc. TAP_RESET is a
+ * stable state, so this must be harmless to all JTAG controllers.
+ */
+ jtag_set_error(interface_jtag_add_runtest(100, TAP_RESET));
+
jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] don't segv certain calls
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] [patch 1/3] add_reset cleanup: shrink work
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] [patch 2/3] add_reset cleanup: TAP_RESET unification
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] [patch 3/3] add_reset cleanup: SRST unification
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] [patch] NEWS updates for 0.3.0
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] OpenOCD 0.2.0 : Olimex ARM-USB-TINY - unable to find driver software
Rohit Chandel pisze: Is there any quick test to find out that openocd is installed correctly? use it. 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
Freddie Chopin wrote: Rohit Chandel pisze: Is there any quick test to find out that openocd is installed correctly? use it. That is funny, and true. But the OpenOcd application is almost always installed correctly and from a users point of view there are lots of things that can go wrong with OpenOCD even if they are not in the strictes sence OpenOcd problems: * Drivers for the JTAG interface must be correctly installed and correspond to the configuration of the OpenOCD installation. * Eclipse must be installed with correct scripts and addons to relibly make gdb talk to OpenOCD * The board/target configuratin scripts must be properly setup. * The application to run on the target and the build configurations must be sound For many users, failure at any of these steps will be interpreted as OpenOCD is not correctly installed because OpenOCD does not solve their problems. It is up to the OpenOCD community to handle this complexity, and if you want OpenOCD to thriwe and grow then this is not an OpenOCD installation problem is NOT the answer. /M ___ 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 Tuesday 25 August 2009, Magnus Lundin wrote: * Eclipse must be installed with correct scripts and addons to relibly make gdb talk to OpenOCD I'd like to see a writeup of what's involved with that for current Eclipse versions become part of the User's Guide ... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] stellaris flash: clocking updates
Clock updates/fixes for the Stellaris flash driver:
- Bugfixes:
* internal osc: it's *12* MHz (not 15 MHz) on _current_ chips
+ except new Tempest parts where it's 16 MHz (and calibrated!)
+ or some old Sandstorm ones, where 15 MHz was valid
* crystal config:
+ read and use the crystal config, don't assume 6 MHz
+ know when that field is 4 bits vs 5
* an RCC2 register may be overriding the original RCC
+ more clock source options
+ bigger dividers
+ fractional dividers on Tempest (NYET handled)
* there's a 30 KHz osc on newer chips (for deep sleep)
* there's a 32768 Hz osc on newer chips (for hibernation)
- Cosmetic
* say rev A0 not vA.0, to match vendor docs
* don't always report master clock as an estimate:
+ give the error bound if it's approximate, like ±30%
+ else don't say anything
* fix whitespace and caps in some messages
* these are not AT91SAM chips!!
Those clock issues might explain problems sometimes reported when
writing to Stellaris flash banks; they affect write timings.
That 12-vs-15 MHz issue is problematic; there's no consolidated doc
showing which chips (and revs!) have which internal oscillator speed.
It's clear that only older silicon had the faster-and-less-accurate
flavor. What's less clear is which chips are old like that.
Lightly tested, on a DustDevil part.
---
src/flash/stellaris.c | 156 ++--
src/flash/stellaris.h |6 +
2 files changed, 143 insertions(+), 19 deletions(-)
--- a/src/flash/stellaris.c
+++ b/src/flash/stellaris.c
@@ -257,7 +257,10 @@ static int stellaris_flash_bank_command(
/* part wasn't probed for info yet */
stellaris_info-did1 = 0;
- /* TODO Use an optional main oscillator clock rate in kHz from arg[6] */
+ /* TODO Specify the main crystal speed in kHz using an optional
+* argument; ditto, the speed of an external oscillator used
+* instead of a crystal. Avoid programming flash using IOSC.
+*/
return ERROR_OK;
}
@@ -294,7 +297,8 @@ static int stellaris_info(struct flash_b
}
printed = snprintf(buf,
buf_size,
- \nLMI Stellaris information: Chip is class %i(%s)
%s v%c.%i\n,
+ \nTI/LMI Stellaris information: Chip is
+ class %i (%s) %s rev %c%i\n,
device_class,
StellarisClassname[device_class],
stellaris_info-target_name,
@@ -305,10 +309,11 @@ static int stellaris_info(struct flash_b
printed = snprintf(buf,
buf_size,
- did1: 0x%8.8 PRIx32 , arch: 0x%4.4 PRIx32 ,
eproc: %s, ramsize:%ik, flashsize: %ik\n,
+ did1: 0x%8.8 PRIx32 , arch: 0x%4.4 PRIx32
+ , eproc: %s, ramsize: %ik, flashsize: %ik\n,
stellaris_info-did1,
stellaris_info-did1,
- ARMV7M,
+ ARMv7M,
(int)((1 + ((stellaris_info-dc0 16)
0x))/4),
(int)((1 + (stellaris_info-dc0 0x))*2));
buf += printed;
@@ -316,9 +321,12 @@ static int stellaris_info(struct flash_b
printed = snprintf(buf,
buf_size,
- master clock(estimated): %ikHz, rcc is 0x% PRIx32
\n,
+ master clock: %ikHz%s,
+ rcc is 0x% PRIx32 , rcc2 is 0x% PRIx32 \n,
(int)(stellaris_info-mck_freq / 1000),
- stellaris_info-rcc);
+ stellaris_info-mck_desc,
+ stellaris_info-rcc,
+ stellaris_info-rcc2);
buf += printed;
buf_size -= printed;
@@ -353,38 +361,103 @@ static uint32_t stellaris_get_flash_stat
/** Read clock configuration and set stellaris_info-usec_clocks*/
+static const unsigned rcc_xtal[32] = {
+ [0x00] = 100, /* no pll */
+ [0x01] = 1843200, /* no pll */
+ [0x02] = 200, /* no pll */
+ [0x03] = 2457600, /* no pll */
+
+ [0x04] = 3579545,
+ [0x05] = 3686400,
+ [0x06] = 400, /* usb */
+ [0x07] = 4096000,
+
+ [0x08] = 4915200,
+ [0x09] = 500, /* usb */
+ [0x0a] = 512,
+ [0x0b] = 600, /* (reset) usb */
+
+ [0x0c] = 6144000,
+ [0x0d] = 7372800,
+ [0x0e] = 800, /* usb */
+ [0x0f] = 8192000,
+
+ /* parts before DustDevil use just 4 bits for xtal spec */
+
+ [0x10] = 1000, /* usb */
+ [0x11] = 1200, /* usb */
+
Re: [Openocd-development] OpenOCD + beagle
On Tuesday 25 August 2009, Øyvind Harboe wrote: I see no problem ... TAP_RESET is a stable state, and JTAG adapters are allowed to let TCK run freely there. But that's not what the code is doing. It goes to TAP_RESET, then cycles 100 times in runtest idle and then back to TAP_RESET Oh; right. Works for Beagle because the TCKs can be in any state; won't work in general ... I guess I would be more comfortable with a change that cycled 100 clocks in reset that's probably harmless everywhere and would let us invent a more generic scheme in time if it ever proved necessary. Right; but there's the TRST path too. (non-sequitor: can we break out new discussion threads a bit more often... easier to track residual issues) OK ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] BeagleBoard and Flyswatter
hi, I've tested 1 and 2 as Dirk suggested. With both versions I get the same results. I'm able to connect jtag consistently and from a telnet session issue the omap3_dbginit command. Lots of improvement from the last time I tried. I try halt, resume, halt and that consistently produces a crash. The gdb of openocd and telnet session is attached, I did not try to debug this further. fred $gdb ./src/openocd GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 02:43:13 UTC 2009) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-apple-darwin...Reading symbols for shared libraries done (gdb) run -s /Users/fred/Documents/openocd/2604/openocd/tcl -f interface/flyswatter.cfg -f board/ti_beagleboard.cfg Starting program: /Users/fred/Documents/openocd/2604/openocd/src/openocd -s /Users/fred/Documents/openocd/2604/openocd/tcl -f interface/flyswatter.cfg -f board/ti_beagleboard.cfg Reading symbols for shared libraries +++ done Open On-Chip Debugger 0.3.0-in-development (2009-08-25-19:51) svn:2604M $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS OLD SYNTAX: DEPRECATED - use jtag_khz, not jtag_speed jtag_speed: 1 Warn : huge IR length 38 Reading symbols for shared libraries . done Info : device: 4 2232C Info : deviceID: 67330064 Info : SerialNumber: FS00 A Info : Description: Flyswatter A Info : clock speed 3000 kHz Info : JTAG tap: omap3530.jrc tap/device found: 0x0b7ae02f (mfg: 0x017, part: 0xb7ae, ver: 0x0) Info : JTAG Tap/device matched Info : accepting 'telnet' connection from 0 Info : JTAG tap: omap3530.jrc tap/device found: 0x0b7ae02f (mfg: 0x017, part: 0xb7ae, ver: 0x0) Info : JTAG Tap/device matched TargetName Type Endian TapNameState -- -- -- -- -- 0* omap3.cpu cortex_a8 little omap3530.dap halted TapName| Enabled | IdCode ExpectedIrLen IrCap IrMask Instr ---||-|||--|--|--|- 0 | omap3530.dsp |n| 0x | 0x | 0x26 | 0x25 | 0x3f | 0x 1 | omap3530.dap |Y| 0x | 0x0b6d602f | 0x04 | 0x01 | 0x0f | 0x0a 2 | omap3530.jrc |Y| 0x0b7ae02f | 0x0b7ae02f | 0x06 | 0x01 | 0x3f | 0x3f background polling: on TAP: omap3530.dap (enabled) target state: halted target halted in ARM state due to debug-request, current mode: System and User cpsr: 0x pc: 0x MMU: disabled, D-Cache: disabled, I-Cache: disabled background polling: on TAP: omap3530.dap (enabled) target state: running Error: invalid mode value encountered Error: invalid mode value encountered Error: invalid mode value encountered Error: invalid mode value encountered Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x02644b74 0x000763cf in cortex_a8_debug_entry (target=0x219130) at cortex_a8.c:599 /Users/fred/Documents/openocd/2604/openocd/src/target/cortex_a8.c:599:18344:beg:0x763cf (gdb) bt #0 0x000763cf in cortex_a8_debug_entry (target=0x219130) at cortex_a8.c:599 #1 0x00077466 in cortex_a8_poll (target=0x219130) at cortex_a8.c:365 #2 0x0009098d in target_wait_state (target=0x219130, state=TARGET_HALTED, ms=7925724) at target.c:1942 #3 0x00090b1b in handle_wait_halt_command (cmd_ctx=0x210850, cmd=0x21b2e0 halt, args=0x22d7d4, argc=0) at target.c:1925 #4 0x00090bee in handle_halt_command (cmd_ctx=0x210850, cmd=0x21b2e0 halt, args=0x22d7d4, argc=0) at target.c:1992 #5 0x000a8e73 in run_command (context=0x210850, c=0x0, words=0x22d7d0, num_words=1) at command.c:415 #6 0x000a90a0 in script_command (interp=0x201800, argc=1, argv=0xbfffeb94) at command.c:142 #7 0x000ba994 in Jim_EvalObj (interp=0x201800, scriptObjPtr=0x22d580) at jim.c:8708 #8 0x000bb74f in Jim_EvalCoreCommand (interp=0x201800, argc=3, argv=0xbfffec84) at jim.c:10846 #9 0x000ba994 in Jim_EvalObj (interp=0x201800, scriptObjPtr=0x22c080) at jim.c:8708 #10 0x000bb672 in Jim_CatchCoreCommand (interp=0x201800, argc=2, argv=0xbfffed74) at jim.c:11413 #11 0x000ba994 in Jim_EvalObj (interp=0x201800, scriptObjPtr=0x22be20) at jim.c:8708 #12 0x000c534b in Jim_EvalExpression (interp=0x201800, exprObjPtr=0x22bc10, exprResultPtrPtr=0xbfffeedc) at jim.c:6927 #13 0x000c5e48 in Jim_GetBoolFromExpr (interp=0x201800, exprObjPtr=0x78efdc, boolPtr=0xbfffef2c) at jim.c:7210 #14 0x000c5f83 in Jim_IfCoreCommand (interp=0x201800, argc=5, argv=0xbfffefb4) at jim.c:10297 #15 0x000ba994 in
[Openocd-development] Eclipse OpenOCD usage documentation, was: OpenOCD 0.2.0 : Olimex ARM-USB-TINY - unable to find driver software
David Brownell wrote: On Tuesday 25 August 2009, Magnus Lundin wrote: * Eclipse must be installed with correct scripts and addons to relibly make gdb talk to OpenOCD I'd like to see a writeup of what's involved with that for current Eclipse versions become part of the User's Guide ... Yes, me too! Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
