Menu
▾
▴
openocd-devel
|
From: Øyvind H. <oyv...@zy...> - 2010-12-05 13:45:40
|
Does anyone have any objections to getting rid of the concept of a default JTAG clock rate? Basically, I'd like OpenOCD to refuse to start until the script defines the clock rate. The actual mechanism needs a bit of though, because it is possible to set jtag clock rate in reset-start and in my book that counts as not using the default clock rate. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer |
|
From: Michael S. <rin...@di...> - 2010-12-05 17:10:06
|
On 12/05/2010 01:45 PM, Øyvind Harboe wrote: > Does anyone have any objections to getting rid of the > concept of a default JTAG clock rate? > > Basically, I'd like OpenOCD to refuse to start until the > script defines the clock rate. Sounds good to me. cu Michael |
|
From: David B. <da...@pa...> - 2010-12-05 17:43:03
|
--- On Sun, 12/5/10, Øyvind Harboe <oyv...@zy...> wrote: > Does anyone have any objections to > getting rid of the > concept of a default JTAG clock rate? NO. But let's see a proposed patch ... :) I recall some discussions a while back about how JTAGKEY2 was broken because its driver was embedding a default clock rate assumption, which broke on some hardware. There have also been related parport issues. > > Basically, I'd like OpenOCD to refuse to start until the script defines the clock rate. Script is the right place, yes. Not *ANY* of the adapter drivers, or embedded in OpenOCD framework code either. > The actual mechanism needs a bit of thought, because it > is possible to set jtag clock rate in reset-start and in > my > book that counts as not using the default clock rate. Right. Reset sequences may need to re-clock, and that's a key hook. Changing SoC clocks tendds to imply a need to update debug adapter clocks (be they JTAG or something else). Fancy reset sequences may end up initializing PLLs and so forth. Fixed clocks are going to break. - Dave |
|
From: Øyvind H. <oyv...@zy...> - 2010-12-06 09:26:19
Attachments:
0001-jtag-getting-the-JTAG-speed-can-fail.patch
|
A starting patch, propagate error for getting speed. In the future it will fail when no jtag speed has been set before someone queries the speed. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer |
|
From: Øyvind H. <oyv...@zy...> - 2010-12-05 17:51:16
|
On Sun, Dec 5, 2010 at 5:43 PM, David Brownell <da...@pa...> wrote: > > > --- On Sun, 12/5/10, Øyvind Harboe <oyv...@zy...> wrote: > >> Does anyone have any objections to >> getting rid of the >> concept of a default JTAG clock rate? > > NO. But let's see a proposed patch ... :) Could you clarify a bit what you are against? A script which has no opinions or references to a JTAG clock is broken and needs user action? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer |
|
From: Øyvind H. <oyv...@zy...> - 2010-12-05 18:17:35
|
More generally, if there is something that user must specify that he hasn't and the script is working by chance, then it would be great if we could robustly detect this situation and require the user to specify that option. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer |
|
From: David B. <da...@pa...> - 2010-12-05 18:18:46
|
> > --- On Sun, 12/5/10, Øyvind Harboe <oyv...@zy...> > wrote: > > > >> Does anyone have any objections to > >> getting rid of the > >> concept of a default JTAG clock rate? > > > > NO. But let's see a proposed patch ... :) > > Could you clarify a bit what you are against? I'll know it if I see it. :) My comment is mostly about being cautious and complete. ISTR seeing defaults get snuck in by several channels (not just drivers). Catching all the side channels may be tricky, but leaving a few could make other changes error-prone... > > A script which has no opinions or references to > a JTAG clock is broken and needs user action? That's a good start; we'd need to fix such scripts (if they're in our GIT tree) before changing current behavior. Also, at which point does the runtime code check to see if a rate was set? best would be a "late" check, shortly before e.g. a JTAG operation needs to rely on a clock rate. An *early* test would inadvisable; e.g. potentially preventing prep or setup that didn't need to use the debug bus. - Dave |
|
From: Laurent G. <lau...@am...> - 2010-12-06 10:16:32
|
> Does anyone have any objections to getting rid of the > concept of a default JTAG clock rate? > > Basically, I'd like OpenOCD to refuse to start until the > script defines the clock rate. > > The actual mechanism needs a bit of though, because it > is possible to set jtag clock rate in reset-start and in my > book that counts as not using the default clock rate. Bad! For me. For me, JTAG is just a transport layer for debugging programming ... Also, the openocd users should not need to play with any JTAG setting as TCK frequency ... The user want to debug their target board, not the JTAG transport layer or JTAG communication !!! ... The best, for me, is to fix a low 1MHz frequency as default frequency without the use of RTCK (disabling RTCK) at the startup of OpenOCD server (example : set the 1MHz frequency and disable RTCK in Amontec JTAGkey-2 (instead 30MHZ with RTCK)). After this default frequency, the scripts may down or up the frequency depending on the specific job. Or the script could call a function able to auto-detect the max frequency and to auto-detect the 'yes' or 'no' of the RTCK use... If there are no specific frequency set in the script, we run at 1MHZ without RTCK. This will minimize the troubles for end users. This 1MHz should not be set by the specific dongle driver itself, but at higher level -> JTAG API. Laurent http://www.amontec.com USB JTAG Adapter Dongle |
|
From: Øyvind H. <oyv...@zy...> - 2010-12-06 10:22:39
|
I don't subscribe to the idea that there is a safe, correct and robust default setting for JTAG clock, better to make the user get a good error message that points him in the right direction. 1MHz will fail on plenty of cards (with RC oscilators typically). -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer |
|
From: Laurent G. <lau...@am...> - 2010-12-06 10:46:31
|
Øyvind Harboe wrote: > I don't subscribe to the idea that there is a safe, correct and robust > default setting for JTAG clock, better to make the user get a > good error message that points him in the right direction. > > 1MHz will fail on plenty of cards (with RC oscilators typically). > > I do not say the 1MHz is safe correct and robust, but having a known 1MHZ JTAG at startup, is is a good way to let the user do something with openocd without having to obligatory set a specific frequency in the script. If the 1MHZ failed, it failed ... and something specific must be present in the script. Xilinx Altera Actel do in this way. THE SAFE CORRECT ROBUST frequency can never be known as static ! A good JTAG software has to find this frequency by itself (auto-detecting the max safe JTAG frequency );-) Too many parameters are around THE SAFE CORRECT ROBUST frequency ;-) --- True regarding the cards with RC oscillator starting at super low frequency as 30KHz, but it is already specific to a target. In this case the 1MHZ should not let to find and detect the chain and we report a error message. The default frequency could be 10KHz instead 1MHZ ... But to set a default frequency at the JTAG API level and at startup is to fix something (something good or not, but FIX). Laurent http://www.amontec.com |
|
From: Øyvind H. <oyv...@zy...> - 2010-12-06 10:54:06
|
For something like OpenOCD where anything could be connected, you will easily end up in a situation that 1MHz kinda works, which is the worst possible situation. Better to tell the user that a configuration script must have made a decision on how to deal with JTAG clock frequency. That decision could be 1MHz, autodetect or whatever, but all configuration scripts are required to make decision. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer |
|
From: Peter S. <pe...@st...> - 2010-12-06 10:54:50
|
Laurent Gauch wrote: > THE SAFE CORRECT ROBUST frequency can never be known as static ! > A good JTAG software has to find this frequency by itself Which is an important usability enhancement that can only be done sensibly *AFTER* there is a proper and enforced way to set the speed. I am sure you understand that things may need to get worse before they can get better. It has already been mentioned on the list that it is obviously correct for OpenOCD to have and use knowledge about components, in order to determine useful values for various parameters. I don't think that needs to be said again. But please do help with the steps that are required to get there. Thanks! //Peter |
|
From: Laurent G. <lau...@am...> - 2010-12-06 11:16:58
|
> > > It has already been mentioned on the list that it is obviously > correct for OpenOCD to have and use knowledge about components, > in order to determine useful values for various parameters. I don't > think that needs to be said again. But please do help with the steps > that are required to get there. out-of-topic comment. Øyvind asked if anyone have any objections to getting rid of the concept of a default JTAG clock rate? Then I've just given my opinion. Laurent http://www.amontec.com |
|
From: David B. <da...@pa...> - 2010-12-06 18:49:28
|
--- On Mon, 12/6/10, Laurent Gauch <lau...@am...> wrote: > > I don't subscribe to the idea that there is a safe, > correct and robust > > default setting for JTAG clock, The only thing that'd prevent a given board from having such a (board-specific) setting is using it with a debug adapter that doesn't support the board's preferred frequency. Trying that must trigger a fatal error from the adapter. That is: any given board/target will have such a setting, which can be saved in a config file. better to make the > user get a > > good error message Good messaging is always good. Just like Bad messaging is always bad... Somewhat tautological. But relying on messaging to achieve proper setup is not very wise. We know that users tend not to read or understand such messaging. Treat such procedures as undesirable fallbacks, except for basic error reporting. Good diagnostics (with "what to do next" advice" are so rare nowadays that I think users will run away in fear if they come across any such. > I do not say the 1MHz is safe correct and robust, but > having a known 1MHZ JTAG at startup, is is a good way to let > the user do something with openocd That presumes, wrongly, that 1 MHZ would work. First time I used OpenOCD was with a 32KHz system clock, so a 1 MHz default would have been a complete and utter lose. without having to > obligatory set a specific frequency in the script. Were it not safe/correct/robust it couldn't work. So don't even bother with it. Remember that the board's frequency only needs to be set once. Once that's done, "the user" has no more setup to handle. In fact, Whoever did the board config file should have handled all such issues, so "the user" never sees them. > THE SAFE CORRECT ROBUST frequency can never be known as > static ! See above. It's board-specific, but can very easily be "known as static" for startup. (And a good config can adapt later, to new PLL settings and so forth.) A good JTAG software has to find this frequency by > itself (auto-detecting the max safe JTAG frequency );-) All JTAGs I've used require manual config for this, since board requirements vary so much, and since detecting that a particular problem was caused by a bad frequency setting isn't very easily automated. There are a LOT of distinct failure modes, but some look like failures of a different kind (e.g. wiring errors). The best way to sort this stuff out involves ways to leverage end-user brains. (and failure modes stying simple enough that they don't need extensive troubleshooting training). |
|
From: Peter S. <pe...@st...> - 2010-12-06 10:29:12
|
David Brownell wrote: > > Basically, I'd like OpenOCD to refuse to start until the script > > defines the clock rate. > > Script is the right place, yes. Not *ANY* of > the adapter drivers, or embedded in OpenOCD > framework code either. I like this. And specifically I think that trying to set speed in those files must generate a fatal error. Laurent Gauch wrote: > Bad! For me. .. > The best, for me, is to fix a low 1MHz frequency as default > frequency without the use of RTCK (disabling RTCK) at the startup Isolating and enforcing exactly where the setting is allowed is of course a neccessary step in the right direction. Usability may be slightly worse in the immediate term with such a change, but having the infrastructure in place to allow verifying that settings can only be done in the correct fashion in the correct places is a fundamental requirement for improving usability *later* e.g. with an algorithm that selects a safe default frequency. //Peter |
|
From: Michael S. <rin...@di...> - 2010-12-06 20:15:05
|
On 12/06/2010 10:53 AM, Laurent Gauch wrote: > > > Øyvind Harboe wrote: >> I don't subscribe to the idea that there is a safe, correct and robust >> default setting for JTAG clock, better to make the user get a >> good error message that points him in the right direction. >> >> 1MHz will fail on plenty of cards (with RC oscilators typically). >> >> > I do not say the 1MHz is safe correct and robust, but having a known > 1MHZ JTAG at startup, is is a good way to let the user do something > with openocd without having to obligatory set a specific frequency in > the script. If the 1MHZ failed, it failed ... and something specific > must be present in the script. 1MHz is just as bad as as default as 30MHz. It may work in more cases, but it is still broken in some. IMHO, there are two possibilities: - we find a method to auto-configure a default that works in *every* case - or we require a configuration value that works (that may be chip- or board-specific). Having a default that works most of the time, but causes strange effects in some cases, is really bad useability. > THE SAFE CORRECT ROBUST frequency can never be known as static ! A > good JTAG software has to find this frequency by itself > (auto-detecting the max safe JTAG frequency );-) Then how do you propose to implement such an auto-detection? > The default frequency could be 10KHz instead 1MHZ ... Until some new really-low-power chip comes along that starts at an even lower internal clock - this does not sound robust. cu Michael |
|
From: Laurent G. <lau...@am...> - 2010-12-07 10:33:21
|
>
> 1MHz is just as bad as as default as 30MHz. It may work in more cases,
> but it is still broken in some.
>
As I said before the 1Mhz startup frequency could be 10kHz. The
important is not the value of the startup frequency, the important is to
know we have a startup frequency !!!
> IMHO, there are two possibilities:
> - we find a method to auto-configure a default that works in *every* case
>
That's the best to do at the end.
> - or we require a configuration value that works (that may be chip- or
> board-specific).
>
Will be never good. A JTAG frequency is not only board specific, but
wire (cable length) dependent, buffer dependend, dongle dependent ....
Too many parameters !!!
> Having a default that works most of the time, but causes strange effects
> in some cases, is really bad useability.
>
The question is what is 'most of time' 80% 90% 99%
Fixing at a default 10KHz frequency will help user to auto-detect their
JTAG chain ... and this is REALLY ever a GOOD thing to know the JTAG
chain is auto-detected -> my JTAG Chain is working, the JTAG transport
layer is working, user are already happy ;-)
Next, is to find the max. safe frequency :-)
>
> >/ THE SAFE CORRECT ROBUST frequency can never be known as static ! A
> />/ good JTAG software has to find this frequency by itself
> />/ (auto-detecting the max safe JTAG frequency );-)
> /Then how do you propose to implement such an auto-detection?
>
Work on 10KHz startup frequency.
READ the TAPID_old (the first TAP ID is enough)
READ the TAPID_new (the first TAP ID is enough)
WHILE TAPID_old = TAPID_new old
up/scale the frequency
TAPID_old <= TAPID_new;
READ the TAPID_new (the first TAP ID is enough)
DO
max safe frequency is TAPID_old
> >/ The default frequency could be 10KHz instead 1MHZ ...
> /Until some new really-low-power chip comes along that starts at an even
> lower internal clock - this does not sound robust.
>
I am almost sure at 10KHz it will be 99% robust -> not enough !
Laurent
Amontec JTAGkey-2 Hi-SPEED USB JTAG CABLE
http://www.amontec.com
|
|
From: Michael S. <rin...@di...> - 2010-12-07 21:40:06
|
On 12/07/2010 10:39 AM, Laurent Gauch wrote: > Will be never good. A JTAG frequency is not only board specific, but > wire (cable length) dependent, buffer dependend, dongle dependent .... > Too many parameters !!! Chip, dongle, board configs could supply max values (and OpenOCD would have to select the lowest of them) - however, the user will have to select the frequency he wants to use, the config values can only limit the user's choice in case he sets a frequency that is too hight for some component. >> Having a default that works most of the time, but causes strange effects >> in some cases, is really bad useability. >> > The question is what is 'most of time' 80% 90% 99% > Fixing at a default 10KHz frequency will help user to auto-detect > their JTAG chain ... and this is REALLY ever a GOOD thing to know the > JTAG chain is auto-detected -> my JTAG Chain is working, the JTAG > transport layer is working, user are already happy ;-) I am not sure 10kHz is good. On a core where the max. JTAG frequency is cpu_clk / 6, with a 32.768kHz crystal, 10kHz is already too high. >> /Then how do you propose to implement such an auto-detection? >> > Work on 10KHz startup frequency. > READ the TAPID_old (the first TAP ID is enough) > READ the TAPID_new (the first TAP ID is enough) > WHILE TAPID_old = TAPID_new old > up/scale the frequency > TAPID_old <= TAPID_new; > READ the TAPID_new (the first TAP ID is enough) > DO > max safe frequency is TAPID_old Probably not. On cores where the JTAG frequency is limited to some fraction of the core frequency due to internal synchronization, you may get a broad area where probing works some of the times, so you would choose a frequency that fails from time to time. cu Michael |
|
From: Øyvind H. <oyv...@zy...> - 2010-12-06 20:33:33
|
I believe that there might exist a safe default or autodetection scheme for a specific family of parts. Such parts could use a common configuration file which did the autodetect/set the robust default frequency. The responsibility for deciding how to deal with JTAG clk is still firmly in the board configuration file though. The board config file might ultimately decide directly or indirectly to use a family-default or autodetect scheme, that was a decision made by the board config file. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer |
|
From: Karl K. <kku...@gm...> - 2010-12-06 20:37:32
|
On Mon, Dec 6, 2010 at 12:33 PM, Øyvind Harboe <oyv...@zy...> wrote: > I believe that there might exist a safe default or autodetection > scheme for a specific family of parts. > > Such parts could use a common configuration file which > did the autodetect/set the robust default frequency. > > The responsibility for deciding how to deal with JTAG clk > is still firmly in the board configuration file though. The > board config file might ultimately decide directly or > indirectly to use a family-default or autodetect scheme, > that was a decision made by the board config file. > > -- > Øyvind Harboe > > Can Zylin Consulting help on your project? > > US toll free 1-866-980-3434 / International +47 51 63 25 00 > > http://www.zylin.com/zy1000.html > ARM7 ARM9 ARM11 XScale Cortex > JTAG debugger and flash programmer > _______________________________________________ > Openocd-development mailing list > Ope...@li... > https://lists.berlios.de/mailman/listinfo/openocd-development > All device vendors should provide BSDL files for their devices which specify the maximum TCK speed the device can support. This can be used to create an auto-configuration that is fairly easy to use and robust. An example of this is the Xilinx programming tools. They do an initial shift at a low speed to find the JTAG ID's of each device. Once the device IDs are found a search is done against the BSDL files to find a matching description. Once that is complete the lowest maximum JTAG speed is used as an initial configuration based on the BSDL information. As an added benefit the JTAG instruction lengths are also defined in the BSDL so it does not need to be configured manually. If you see failures then you have the option of manually lowering the maximum JTAG frequency which overrides the BSDL files. -Karl |
|
From: David B. <da...@pa...> - 2010-12-06 21:31:20
|
--- On Mon, 12/6/10, Karl Kurbjun <kku...@gm...> wrote: > All device vendors should provide BSDL files for their devices Yes, and they're not necessarily easy to find. which > specify the maximum TCK speed the device can support. On appropriately designed and manufactured boards, only. So that's an optimistic upper bound, not necessarily a sane default. Also, not available to OpenOCD at this time since we have neither a BSDL parser, or places to store the information one would report. It ought to integrate with SVF and XSVF, as one example I seem to recall: pin/ball assignments and all that stuff. I don't think we should require folk to get and use BSDL files for their chips, though I'd have nothing against using that data if it were handy. They can currently just read the files and put that data into the chip config files (lots of those config files were done that way). Of cou |
|
From: Laurent G. <lau...@am...> - 2010-12-07 10:40:21
|
> > All device vendors should provide BSDL files for their devices which > specify the maximum TCK speed the device can support. This can be > used to create an auto-configuration that is fairly easy to use and > robust. > > An example of this is the Xilinx programming tools. They do an > initial shift at a low speed to find the JTAG ID's of each device. > Once the device IDs are found a search is done against the BSDL files > to find a matching description. Once that is complete the lowest > maximum JTAG speed is used as an initial configuration based on the > BSDL information. As an added benefit the JTAG instruction lengths > are also defined in the BSDL so it does not need to be configured > manually. > > If you see failures then you have the option of manually lowering the > maximum JTAG frequency which overrides the BSDL files. > > -Karl > BSDL give some informations as max JTAG frequency. The bad things are : - not all devices come with BSDL (in general the device not supporting the boundary scan, do not provide BSDL files -> low cost LPC parts ...) - Amontec has found that the frequency notified in the BSDL file is not really the maximum frequency but sometimes absolute max frequency - 50%! The BSDL are not really a good thing for the major work of openocd user doing on-chip debug -> and not on-board debug (boundary scan) Regards, Laurent |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X