On Friday 22 May 2009 20:16:14 Michael Schwingen wrote:
> Raúl Sánchez Siles wrote:
> > Hello all:
> >
> > This start a patchset series for implementing x16_as_x8 cfi compliant
> > feature.
> >
> > · 01-x16_as_x8-consolidate_addresses.patch
> > · 02-x16_as_x8-flash_address.patch
> > · 03-
Hi all,
I'm unable to compile latest trunk with ftd2xx library. Linker fails with the
following error:
make[3]: Entering directory `/usr/src/openocd/trunk/src'
/bin/sh ../libtool --tag=CC --mode=link
gcc -std=gnu99 -g -O2
-I/home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64 -Wa
On Mon, May 25, 2009 at 4:53 PM, Vytautas Lukenskas
wrote:
> I'm unable to compile latest trunk with ftd2xx library. Linker fails with the
> following error:
> ./.libs/libopenocd.so: undefined reference to `FT_GetLatencyTimer'
>
I do not use Linux x86_64 and FTD2xx but when I encounter similar p
On Mon, May 25, 2009 at 11:28 AM, Xiaofan Chen wrote:
>
> There are many 16/32bit MCUs which will benefit from OpenOCD if
> they are supported. Most popular non-ARM ones I can think of are Renesas
> M16C/32C, H8/H8S/H8SX, Infineon XC166/XE166, TI MSP430.
>
> Just look at this chart for top 10 MCU
> -Oorspronkelijk bericht-
> Van: openocd-development-boun...@lists.berlios.de
> [mailto:openocd-development-boun...@lists.berlios.de] Namens
> Xiaofan Chen
> Verzonden: maandag 25 mei 2009 10:54
> Aan: openocd-development@lists.berlios.de
> Onderwerp: Re: [Openocd-development] support av
Michel Catudal wrote:
> A MIPS question for those who know. Is there a usefull debug module in
> the NEC V850? I would think that it would have at least the standard
> MIPS module.
> Am I wrong to think that? According to NEC and IAR the only way to debug
> is to use the minicube.
>
> Michel
>
>
Hallo Vytautas,
I had the same error yesterday. It seems that you have to change the
order of the commandline in this way:
gcc ... .libs/libopenocd.so
/home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64/static_lib/libftd2xx.a.0.4.16
-ldl -lpthread
Regards,
Hubert
On Mon, May 25, 2009
On Monday 25 May 2009 11:59:42 Xiaofan Chen wrote:
> I usually re-run bootstrap or to pull the subversion source again. Maybe
> you can try this.
Yes, I've tried that already... It doesn't help.
--
vylu
___
Openocd-development mailing list
Openocd-deve
duane>[about irqs during resume]
Magnus Lundin> [look here]
> int arm7_9_debug_entry(target_t *target)
> Look for buf_set_u32(dbg_ctrl->value, EICE_DBG_CONTROL_INTDIS, ...
> and the debug_execution flag.
Yes, I see that now, thank you.
it is the last parameter to the RESUME function.
I notic
On Monday 25 May 2009 13:28:03 Hubert Hoegl wrote:
> I had the same error yesterday. It seems that you have to change the
> order of the commandline in this way:
>
> gcc ... .libs/libopenocd.so
> /home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64/static_lib/lib
>ftd2xx.a.0.4.16 -ldl -lpt
On Sun, May 24, 2009 at 11:10 PM, Michael Fischer wrote:
> Hello Xiaofan,
>
> I have tesed to flash the program here. I could flash it
> with my ft2232 device. I do not check the functionality
> of the program itself, LED1 was flashing.
And you can switch on/off LED 2 by pressing the
two switches
On Mon, May 25, 2009 at 7:31 PM, Xiaofan Chen wrote:
> I will try with the J-Link V6 a bit later and report.
>
Somehow 1906 can not connect to my J-Link V6 with your script.
mc...@ubuntu904:~/Desktop/build/openocd/jlinkv6$ openocd -f jlink.cfg
Open On-Chip Debugger 0.2.0-in-development (2009-05
On Mon, May 25, 2009 at 7:43 PM, Xiaofan Chen wrote:
>> I will try with the J-Link V6 a bit later and report.
>>
> Somehow 1906 can not connect to my J-Link V6 with your script.
With the simple script, V1906 can talk to J-Link V6. It seems to
work with your simple LED 1/2 blinking hex file. I tri
On Mon, May 25, 2009 at 8:02 PM, Xiaofan Chen wrote:
> With the simple script, V1906 can talk to J-Link V6. It seems to
> work with your simple LED 1/2 blinking hex file. I tried both
> jlink_hw_jtag 2 or 3.
>
> More tests to follow.
But it still does not work with the lpcusb isoc hex file.
mc.
On Mon, May 25, 2009 at 8:09 PM, Xiaofan Chen wrote:
> On Mon, May 25, 2009 at 8:02 PM, Xiaofan Chen wrote:
>> With the simple script, V1906 can talk to J-Link V6. It seems to
>> work with your simple LED 1/2 blinking hex file. I tried both
>> jlink_hw_jtag 2 or 3.
>>
>> More tests to follow.
>
On Sun, May 24, 2009 at 5:59 PM, Michael Fischer wrote:
>
> But it could be possible that the J-Link had a problem too.
>From all the tests, it seems to me that it is a J-Link problem.
It seems to me that you can flash the LPC-2148 with ft2232
interface or with the Segger J-Flash using J-Link. Bu
On Sat, May 23, 2009 at 8:49 AM, Dylan Reid wrote:
> static int jlink_get_version_info(void)
>
> The crazy thing is that sometimes this works. Often enough to be
> usable actually. I added a check to jlink_usb_read and it makes it
> fail every time. I attached the patch as I think it is the rig
I'll fix below:
1. setup svf tap state names instead of using tap_state_name
Return values of tap_state_name is now non-svf-standard.
So I cannot use this function to setup svf tap state names.
2. malloc memory automatically to handle with any size of tap scan
I'll provide first the patch to fix 1
Is there any particular reason why the JTAG layer uses hardware resets (TRST)?
I would assume that the most portable way to go to TLR, the one that
works even if all reset lines are missing or are not yet or
incorrectly configured would be to shift out five HIGH bits which
leads to TLR regardless
On Mon, May 25, 2009 at 8:13 PM, Xiaofan Chen wrote:
>>> With the simple script, V1906 can talk to J-Link V6. It seems to
>>> work with your simple LED 1/2 blinking hex file. I tried both
>>> jlink_hw_jtag 2 or 3.
>>>
>>> More tests to follow.
>>
>> But it still does not work with the lpcusb isoc
On Mon, May 25, 2009 at 9:46 PM, Xiaofan Chen wrote:
>>> But it still does not work with the lpcusb isoc hex file.
>
> According to vbindiff report of the dump file, the first 0x160
> portion of the dump is not correct. Other than that, it seems
> to be ok.
>
> dump_isoc.bin is from OpenOCD.
> iso
On Mon, May 25, 2009 at 9:56 PM, Xiaofan Chen wrote:
> On Mon, May 25, 2009 at 9:46 PM, Xiaofan Chen wrote:
But it still does not work with the lpcusb isoc hex file.
>>
>> According to vbindiff report of the dump file, the first 0x160
>> portion of the dump is not correct. Other than that, i
Hi Michael,
On 5/25/09, Michael Bruck wrote:
> Is there any particular reason why the JTAG layer uses hardware resets
> (TRST)?
>
> I would assume that the most portable way to go to TLR, the one that
> works even if all reset lines are missing or are not yet or
> incorrectly configured would be
On Mon, May 25, 2009 at 9:58 PM, Xiaofan Chen wrote:
> On Mon, May 25, 2009 at 9:56 PM, Xiaofan Chen wrote:
>> On Mon, May 25, 2009 at 9:46 PM, Xiaofan Chen wrote:
> But it still does not work with the lpcusb isoc hex file.
>>>
>>> According to vbindiff report of the dump file, the first 0x1
This patch setup svf tap name in svf.c instead of calling tap_state_name.
2009-05-25
Best Regards, Simon Qian
SimonQian(simonq...@simonqian.com) www.SimonQian.com
svf_tap_name_20090525.patch
Description: Binary data
___
Openocd-development ma
On Mon, May 25, 2009 at 10:09 AM, Xiaofan Chen wrote:
> Now we are testing other hex file. I believe there may be two issues
> involved after Michael fixed the checksum issue for lpc-2148.
>
> 1) Potential J-Link stability issues. I will check out V6. If it is ok
> and V3 is not, then V3/V4 may n
On Sun, May 24, 2009 at 12:36 PM, Zach Welch wrote:
> The following issues have been reported and should try to be resolved:
> - flashing on LPC-P2148 (Xiaofan Chen)
Just want to say that this problem is now solved. Please refer to the
other thread about the solution. I need to erase the first ba
In R.Doss's svf test, his svf file has a very large scan,
size of which is 2732719 bits. This scan should be processed
in one jtag_add_plain_dr_scan.
But as I remember, driver of jlink doesn't support that
size, and versaloon driver should also be modified.
2009-05-25
Best Regards, Simon Q
On Sat, 23 May 2009, David Brownell wrote:
> I see messages about needing to increase some GDB timeout/interval. But
> that's foolishness, since I'm not even working with GDB when they start
> spamming me.
This is indeed really irritating.
What about those messages being displayed only when a g
On Sun, 24 May 2009, Rick Altherr wrote:
>
> On May 24, 2009, at 9:37 PM, Zach Welch wrote:
>
> > On Sun, 2009-05-24 at 21:19 -0700, Rick Altherr wrote:
> > > =On May 24, 2009, at 9:04 PM, Zach Welch wrote:
> > >
> > > > On Sun, 2009-05-24 at 20:51 -0700, David Brownell wrote:
> > > > > On Sund
Xiaofan Chen a écrit :
> 2009/5/25 Michel Catudal :
>
>> A MIPS question for those who know. Is there a usefull debug module in
>> the NEC V850? I would think that it would have at least the standard
>> MIPS module.
>> Am I wrong to think that? According to NEC and IAR the only way to debug
>> i
2009/5/25 Michel Catudal :
> Some devices can be bought at relatively low price for personal designs,
> so it is not just for us in the automotive industry.
> http://www.futureelectronics.com/en/Search.aspx?dsNav=Ntk:PartNumberSearch|V850|1|,Ny:True,Nea:True
I've seen a few designs with NEC V850 (
This patch has some problems, in the recent jtag.h, tap states are
different from original settings.
I'll provide another patch soon.
2009-05-25
Best Regards, Simon Qian
SimonQian(simonq...@simonqian.com) www.SimonQian.com
发件人： SimonQian
发送时间： 2009-05-25 22:03:56
收件人： Openocd-Dev
Hello:
On Friday 22 May 2009 20:16:14 Michael Schwingen wrote:
> Raúl Sánchez Siles wrote:
> > Hello all:
> >
> > This start a patchset series for implementing x16_as_x8 cfi compliant
> > feature.
> >
> > · 01-x16_as_x8-consolidate_addresses.patch
> > · 02-x16_as_x8-flash_address.patch
>
Xiaofan Chen a écrit :
> On Mon, May 25, 2009 at 11:28 AM, Xiaofan Chen wrote:
>
>> There are many 16/32bit MCUs which will benefit from OpenOCD if
>> they are supported. Most popular non-ARM ones I can think of are Renesas
>> M16C/32C, H8/H8S/H8SX, Infineon XC166/XE166, TI MSP430.
>>
>> Just l
This patch add tap_state_svf_name in svf.c.
Change RUN/IDLE to IDLE. IDLE is svf standard.
2009-05-25
Best Regards, Simon Qian
SimonQian(simonq...@simonqian.com) www.SimonQian.com
发件人： SimonQian
发送时间： 2009-05-25 23:15:58
收件人： SimonQian; Openocd-Dev
抄送：
主题： Re: [Openocd-developme
Duane Ellis a écrit :
>
> I doubt the V850 would ever be supported by openocd. Reason: Support
> for it in GCC is long dead (dormant?), along with support for it in
> GDB, those two things have to come first.
>
> -Duane.
>
>
>
The V850E is the latest and the latest GCC is working relatively well
fr
Committed revision 1911.
On May 25, 2009, at 8:22 AM, Raúl Sánchez Siles wrote:
Hello:
On Friday 22 May 2009 20:16:14 Michael Schwingen wrote:
Raúl Sánchez Siles wrote:
Hello all:
This start a patchset series for implementing x16_as_x8 cfi
compliant
feature.
· 01-x16_as_x8-consolid
Committed revision 1912.
On May 25, 2009, at 8:34 AM, SimonQian wrote:
This patch add tap_state_svf_name in svf.c.
Change RUN/IDLE to IDLE. IDLE is svf standard.
2009-05-25
Best Regards, Simon Qian
SimonQian(simonq...@simonqian.com) www.SimonQian.com
发件人： SimonQian
发送时间： 2009-05-25 23
Nico Coesel a écrit :
> FYI:
> Coldfire = 68000
> Codesourcery offers precompiled GCC with Coldfire support. Maybe
> Freescale can be persuaded to donate some hardware. They are losing
> designs because they are currently forcing their customers to use
> Codewarrior.
>
The Codewarrior crap is j
Xiaofan Chen a écrit :
> 2009/5/25 Michel Catudal :
>
>> Some devices can be bought at relatively low price for personal designs,
>> so it is not just for us in the automotive industry.
>> http://www.futureelectronics.com/en/Search.aspx?dsNav=Ntk:PartNumberSearch|V850|1|,Ny:True,Nea:True
>>
On Monday 25 May 2009, Nicolas Pitre wrote:
> On Sat, 23 May 2009, David Brownell wrote:
>
> > I see messages about needing to increase some GDB timeout/interval. But
> > that's foolishness, since I'm not even working with GDB when they start
> > spamming me.
>
> This is indeed really irritating
Magnus Lundin wrote:
> Dick Hollenbeck skrev:
>> Zach,
>>
>> I think this patch is fundamentally wrong and is a disaster the
>> moment it is applied.
>>
>> The queue sits between the jtag api and the drivers. The api calls
>> track "future" state according to the most recent api call submitted
Xiaofan Chen a écrit :
> At that time, NEC documentation is quite bad. Their emulator was
> very expensive. NEC chips seemed to be ok then. Luckily I
> chose Microchip and not Atmel AT90S AVR since Atmel obsoleted
> all the AT90S AVR over the years and the product needs to be
> in the market for 10
Nicolas Pitre a écrit :
>
>
> As far as my opinion matters, I don't think that uint32_t is that much
> clearer than u32. It is widely assumed that u32 refers to an integer
> and not a float, hence having the information carried everywhere is up
> only for additional typing and screen realestate
Magnus Lundin wrote:
> Hi
>
> I was testing the state move work fronm Dick H. when there were a lot
> of changes in the codebase. As you know I keep working from the same
> base . There were some problems remaining so I have waited to send the
> results, but I hope I found most of them now.
>
>
Add svf_get_mask_u32 to generate a mask according to bitlen.
Fix this bug in other functions except for svf_check_tdo.
Next patch will fix the segfault reported by R.Doss.
2009-05-26
Best Regards, Simon Qian
SimonQian(simonq...@simonqian.com) www.SimonQian.com
svf_32bit_bug_20090526_
Dick Hollenbeck wrote:
> Magnus Lundin wrote:
>> Hi
>>
>> I was testing the state move work fronm Dick H. when there were a lot
>> of changes in the codebase. As you know I keep working from the same
>> base . There were some problems remaining so I have waited to send
>> the results, but I hope
This patch fix segfault reported by R.Doss.
TODO:
R.Doss's svf file has a very large scan:
SDR 2732719 TDI
(0002000200020002000200020002000200020002000200020002000200020002580042861..
Size of this scan is 2732719 bits.
It sould be processed with one jtag_add_plain_dr_scan.
Does all IF drivers
Unsubscribe.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Michael Bruck wrote:
> Is there any particular reason why the JTAG layer uses hardware resets (TRST)?
>
> I would assume that the most portable way to go to TLR, the one that
> works even if all reset lines are missing or are not yet or
> incorrectly configured would be to shift out five HIGH bits
On Sun, 2009-05-24 at 22:43 -0700, Rick Altherr wrote:
> On May 24, 2009, at 9:37 PM, Zach Welch wrote:
>
> > On Sun, 2009-05-24 at 21:19 -0700, Rick Altherr wrote:
> >> =On May 24, 2009, at 9:04 PM, Zach Welch wrote:
> >>
> >>> On Sun, 2009-05-24 at 20:51 -0700, David Brownell wrote:
> On Su
On May 25, 2009, at 17:41, Nicolas Pitre wrote:
> As far as my opinion matters, I don't think that uint32_t is that much
> clearer than u32.
It is however what the language standard specifies, and provided by
the compiler. Complaints that the C99 type definitions are so much
more difficult to
On May 25, 2009, at 12:28 PM, Zach Welch wrote:
1) It's shorter/faster to type. This argument has been hashed out
extensively on the Linux mailing lists. Linus has it right in this
debate to prefer s32/u32. POSIX is dumb; however, that doesn't mean
we
can't exploit their work for own purpos
zach>
> Sorry Rick, but I think that you and Duane have lost this argument.
> You have failed to defend your position with facts.
>
It's hard to 'defined my position' - when I asked this last night 9pm -
and left early this AM to spend a good part of memorial day holiday on a
sail boat (what
Rick Altherr a écrit :
> Perhaps I'm jaded from writing code for OS X where function names are
> intended to be descriptive and thus end up long. Most editors include
> autocompletion which makes the difference minimal in practice. Even
> when I'm writing code in vi, I prefer the longer type name
On May 25, 2009, at 1:21 PM, Duane Ellis wrote:
zach>
Sorry Rick, but I think that you and Duane have lost this argument.
You have failed to defend your position with facts.
I was asking more for an opinion, and the *REASON* I wanted to ask
this was the recent rash of "printf()" formatte
Rick Altherr wrote:
>
> New developers to the project. Not all advanced coders _prefer_
> shorter names just to save on typing. I'm not suggesting we
> "dumb-down" anything. Using cryptic short names to save on typing is
> an elitist attitude that makes the barrier to entry for new developers
>
On Mon, 2009-05-25 at 13:10 -0700, Rick Altherr wrote:
[snip]
> > Sorry Rick, but I think that you and Duane have lost this argument.
> > You have failed to defend your position with facts.
>
> I could say the same of everyone else. Considering the entire issue
> is rooted in preference, there ar
On Mon, 2009-05-25 at 16:21 -0400, Duane Ellis wrote:
> zach>
> > Sorry Rick, but I think that you and Duane have lost this argument.
> > You have failed to defend your position with facts.
> >
>
> It's hard to 'defined my position' - when I asked this last night 9pm -
> and left early this AM
On Monday 25 May 2009, Duane Ellis wrote:
> David's statement: "they look and smell long, like an elephant" - while
> funny, I agree with him 100%, that view has no technical component.
;)
I'd say that "easier to type" is technical. It might not be
compelling, but ... the whole reason there ar
On May 25, 2009, at 1:52 PM, Zach Welch wrote:
On Mon, 2009-05-25 at 13:10 -0700, Rick Altherr wrote:
[snip]
Sorry Rick, but I think that you and Duane have lost this argument.
You have failed to defend your position with facts.
I could say the same of everyone else. Considering the entire
On Monday 25 May 2009, Michael Bruck wrote:
> My suggestion would be to expose the resets as a generic GPIO layer
> that is available to scripts.
That might be generally useful. Example, Texas Instruments
routinely bundles EMU0 and EMU1 signals with their JTAG
adapters.
Near as I can tell, they
On Mon, 2009-05-25 at 14:01 -0700, Rick Altherr wrote:
> On May 25, 2009, at 1:52 PM, Zach Welch wrote:
>
> > On Mon, 2009-05-25 at 13:10 -0700, Rick Altherr wrote:
> > [snip]
> >
> >>> Sorry Rick, but I think that you and Duane have lost this argument.
> >>> You have failed to defend your positio
On Mon, 2009-05-25 at 14:38 -0700, Rick Altherr wrote:
> On May 25, 2009, at 2:24 PM, Zach Welch wrote:
>
> >>> Further, you can argue with the following assertions -- only if you
> >>> can
> >>> show me a patch that proves them wrong:
> >>>
> >
> > Show me your patch, or let me commit mine. This
On May 25, 2009, at 2:50 PM, Zach Welch wrote:
On Mon, 2009-05-25 at 14:38 -0700, Rick Altherr wrote:
On May 25, 2009, at 2:24 PM, Zach Welch wrote:
Further, you can argue with the following assertions -- only if
you
can
show me a patch that proves them wrong:
Show me your patch, or let
On Monday 25 May 2009, Rick Altherr wrote:
> >>> Show me your patch, or let me commit mine. This debate is silly.
My two cents: Commit Zach's patch, since it ends up
resolving potential bugs with e.g. "u32" != "uint32_t".
Then put the debate off to the side for a while. Arguing
like that is co
To move the discussion onto something that miqht require a bit o f real
analysis:
Why does some targets work better during "reset halt" when the
TAP_RESET-> IR_SHIFT is B8(0011000,7) instead of B8(0011011,7) .
And the hard question: why does the first variant work for the ft2232
driver
Hello,
I would like to do a boundary scan on a imx27 part. I've looked through the
documentation and mailing list and I don't see much on this. The most
helpful thing has been a very short wikipedia entry on the SVF format (
http://en.wikipedia.org/wiki/Serial_Vector_Format). I do see the svf comm
Update the "Reset Configuration" information in the User's guide:
- Convert to @deffn syntax
- Move tutorial text from command descriptions into new sections
- Describe several different types of JTAG-visible reset
- Expand descriptions of configuration tweaks for SRST and TRST
- Link to the
On Mon, 2009-05-25 at 15:02 -0700, Rick Altherr wrote:
> On May 25, 2009, at 2:50 PM, Zach Welch wrote:
>
> > On Mon, 2009-05-25 at 14:38 -0700, Rick Altherr wrote:
> >> On May 25, 2009, at 2:24 PM, Zach Welch wrote:
> >>
> > Further, you can argue with the following assertions -- only if
>
On Monday 25 May 2009, David Brownell wrote:
> - Bugfix the "reset_config" description (it didn't match the code)
To recap, current code says the syntax is:
reset_config signals [combination [trst_type [srst_type]]]
PROPOSAL 1: make it so any of those magic keywords can be provided,
in any o
On May 25, 2009, at 3:37 PM, Zach Welch wrote:
The opposing patch is attached. As I already mentioned, it is
large,
but the changes were done entirely with the following commands:
find . -name \*.[ch] -exec sed -i .old -e 's/u8/uint8_t/g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/u
2009/5/25 Michel Catudal :
>> Within theses chips and ColdFire, Infineon XE166 does not seem to have gcc
>> support.
>
> Incorrect, I have one, do you need it? I could provide some binaries on
> my web site if I have space left.
> It is about two years old, I am trying to get the lastest source bu
Does anyone have the device cfg file for TMS470 chips, like TMS470R1A256?
I searched the mailing list archive and it seems that it should work. But I
could not find a cfg file for it. How should I write the cfg file for it?
For the V6 Jlink (my V3 does not seem to work) and the IAR Kickstart board
On Mon, 2009-05-25 at 16:02 -0700, Rick Altherr wrote:
> On May 25, 2009, at 3:37 PM, Zach Welch wrote:
>
> The opposing patch is attached. As I already mentioned, it is
> large,
> but the changes were done entirely with the following commands:
>
> find . -name \*.[ch]
On Mon, 2009-05-25 at 15:21 -0700, Paul Thomas wrote:
> Hello,
>
> I would like to do a boundary scan on a imx27 part. I've looked
> through the documentation and mailing list and I don't see much on
> this. The most helpful thing has been a very short wikipedia entry on
> the SVF format (http://e
Xiaofan Chen a écrit :
> 2009/5/25 Michel Catudal :
>
>
>>> Within theses chips and ColdFire, Infineon XE166 does not seem to have gcc
>>> support.
>>>
>> Incorrect, I have one, do you need it? I could provide some binaries on
>> my web site if I have space left.
>> It is about two years
On Mon, 2009-05-25 at 15:34 -0700, David Brownell wrote:
> Update the "Reset Configuration" information in the User's guide:
>
> - Convert to @deffn syntax
> - Move tutorial text from command descriptions into new sections
> - Describe several different types of JTAG-visible reset
> - Expand d
On May 25, 2009, at 5:07 PM, Zach Welch wrote:
On Mon, 2009-05-25 at 16:02 -0700, Rick Altherr wrote:
On May 25, 2009, at 3:37 PM, Zach Welch wrote:
The opposing patch is attached. As I already mentioned, it is
large,
but the changes were done entirely with the following commands:
find . -
2009/5/26 Michel Catudal :
> Then Fedora 9 should work for you if my Ubuntu script is not complete for
> that. I know it will compile on Fedora 9 but not sure yet on Ubuntu.
> I will have the binary and source by week end.
Thanks a lot. I will take a look. I have a starter kit for XE166 but
I have
On Tue, May 26, 2009 at 8:17 AM, Zach Welch wrote:
> I recently added "BSDL support" to a pending patch to The List of tasks
> to consider for the future, but any kind of "full" boundary scan support
> would be great for OpenOCD to have in-tree and documented.
>
What about the 3rd choice STAPL (o
On Tue, 2009-05-26 at 00:34 +0800, SimonQian wrote:
> Add svf_get_mask_u32 to generate a mask according to bitlen.
> Fix this bug in other functions except for svf_check_tdo.
>
> Next patch will fix the segfault reported by R.Doss.
>
Committed, r1914.
_
On Tue, 2009-05-26 at 02:03 +0800, SimonQian wrote:
> This patch fix segfault reported by R.Doss.
>
Committed, r1915.
--Z
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-deve
On Monday 25 May 2009, Rick Altherr wrote:
> >
> > Actually, David Brownell agrees that it does fix bugs regarding
> > portability of the existing definitions in types.h.
> >
> > Perhaps your passion for this debate clouded your sight to that fact.
> >
>
> Trust me, there is no passion on this end
> > When I do scan_chain
> > I get both imx27.bs and imx27.cpu which looks normal.
Maybe for i.MX27 ... having a separate TAP for boundary
scan seems unusual to me.
ISTR that most ARM cores are set up so that they have an
integrator-provided scan chain (plus the EmbeddedICE,
maybe an
On Sat, 2009-05-23 at 21:55 -0700, Zach Welch wrote:
[snip]
> 2) move board, target, and interface Jim script directories to src/tcl/
> - this will move the whole directories intact, parallel to tcl/chip.
> - more structure can be added, if we see fit; this is a small step.
> -
> http://www
Hi all,
I started this outline of my "smoketest" plans as a reply to David, but
it grew enough to deserve spawning its own new thread.
On Sun, 2009-05-24 at 14:20 -0700, David Brownell wrote:
> On Saturday 23 May 2009, Zach Welch wrote:
> > 5) commit testing tools
> > - one-step smoke tests!
As Zach Welch mentioned, my posts breaks the thread.
I don't know why, and even don't know how to break it.
I'll switch to GMail for OpenOCD maillist.
Should it be working properly?
2009-05-26
Best Regards, Simon Qian
SimonQian(simonq...@simonqian.com) www.SimonQian.com
_
On Tue, 2009-05-26 at 11:36 +0800, SimonQian wrote:
> As Zach Welch mentioned, my posts breaks the thread.
Translation: for some reason he and a few others' replies are often (but
not always) threaded incorrectly in some e-mail readers.
To give a basis for comparison, look at the BerliOS archive
On May 25, 2009, at 6:31 PM, David Brownell wrote:
On Monday 25 May 2009, Rick Altherr wrote:
Actually, David Brownell agrees that it does fix bugs regarding
portability of the existing definitions in types.h.
Perhaps your passion for this debate clouded your sight to that
fact.
Trust
It appears that his mailer (Foxmail according to the headers) doesn't
include the References: header when replying.
Rick
On May 25, 2009, at 9:03 PM, Zach Welch wrote:
On Tue, 2009-05-26 at 11:36 +0800, SimonQian wrote:
As Zach Welch mentioned, my posts breaks the thread.
Translation: fo
2009/5/26 SimonQian :
> As Zach Welch mentioned, my posts breaks the thread.
> I don't know why, and even don't know how to break it.
> I'll switch to GMail for OpenOCD maillist.
> Should it be working properly?
Yes Gmail is a very good option for mailing list. It
works very well. The worst may be
On Tue, May 26, 2009 at 12:03 PM, Zach Welch wrote:
> On Tue, 2009-05-26 at 11:36 +0800, SimonQian wrote:
>> As Zach Welch mentioned, my posts breaks the thread.
>
> Translation: for some reason he and a few others' replies are often (but
> not always) threaded incorrectly in some e-mail readers.
Who maintains these OpenOCD files?
The c01.cfg and c02.cfg files differ only in the PID:
interface ft2232
ft2232_layout jtagkey
ft2232_device_desc "USB-A9260 A"
ft2232_vid_pid 0x0403 0x6010
script interface/calao-usb-a9260.cfg
script target/at91sam9
On Tue, 2009-05-26 at 12:54 +0800, Xiaofan Chen wrote:
> On Tue, May 26, 2009 at 12:03 PM, Zach Welch wrote:
> > On Tue, 2009-05-26 at 11:36 +0800, SimonQian wrote:
> >> As Zach Welch mentioned, my posts breaks the thread.
> >
> > Translation: for some reason he and a few others' replies are often
Hi,
2009/5/26 Xiaofan Chen :
> Does anyone have the device cfg file for TMS470 chips, like TMS470R1A256?
> I searched the mailing list archive and it seems that it should work. But I
> could not find a cfg file for it. How should I write the cfg file for it?
I have working configuration for TMS470
Make it so the magic "reset_config" keywords can be provided in any
order. Example, "trst_and_srst" after "srst_open_drain", omitting
the "separate" combination (which should be the default in any case).
Why? (a) Makes it easier to define things at the right
level (adapter, board
98 matches
Mail list logo
