en it makes sense to treat them as a
closely-relate family. Then we have separate Cortex R and Cortex M
support.
Now that I'm inside ARM I poke people about OpenOCD when I get the
chance. The people here have lots of access to the really expensive
stuff so openOCD is not that high on the rad
as it can
make openocd updates in production environments very awkward..
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
essor ;-)
Does this require something special in use or config to realise? We
saw no, or only a few percent, speedup moving from JTAGkey-tiny to
JTAGkey2. (talking to balloon3 pxa270 board (and Xilinx coolrunnerIII
CPLD).
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
h
enocd program
> jtag_ntrst_delay 250
Try upping these numbers? I know that Marvell parts have different
timing to Intel parts in reset. Bit of a long short but worth a try.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
__
uint8_t
*buffer, uint32_t offset,
return cfi_reset(bank);
}
-static void cfi_fixup_atmel_reversed_erase_regions(struct flash_bank *bank,
void *param)
+static void cfi_fixup_reversed_erase_regions(struct flash_bank *bank, void
*param)
{
(void) param;
struct cfi_flash_bank *cf
+++ David Brownell [2010-05-19 19:55 -0700]:
>
>
> --- On Wed, 5/19/10, Wookey wrote:
>
> > v0.4 requires this:
> > flash bank nand cfi 0x 0x80 2 2 0
>
> Really???
>
> That looks deeply broken. NAND and CFI commands work very differently..
defining things so it will always work?
(strangely the 0.4.0 syntax seemed to work on the v0.3.0 I had
packaged locally, but it doesn't work on the 0.3.1 from Debian, giving:
"Error: target '2' not defined"
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emd
Oddly we have two different in-house interface
boards. Jtagkey2 used to only work with one (but since 0.3 works with
both), Olimex tiny only works with the other. I have not yet worked
out whay this is.
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill
+++ David Brownell [2009-10-29 12:37 -0700]:
> On Thursday 29 October 2009, Wookey wrote:
> >
> > Cheers very much for that. Now to see if the 'only works on amd64' and
> > 'only works every other time' bugs from r1613 have gone in latest :-)
>
&g
+++ David Brownell [2009-10-27 19:17 -0700]:
> On Tuesday 27 October 2009, Wookey wrote:
> > > So if I whack together a patch turning XSVF's (c) into
> > > the (b) which is supported, you could test it and maybe
> > > fix any goofs?
> >
>
+++ David Brownell [2009-10-27 11:30 -0700]:
> On Tuesday 27 October 2009, Wookey wrote:
> > > Does that SVF version work OK?
> >
> > No, but then I wouldn't expect it to in this case. The xsvf command
> > allows the specification of a tap which means that an XS
+++ David Brownell [2009-10-26 12:02 -0700]:
> On Monday 26 October 2009, Wookey wrote:
> > OK. results of today's testing on 0.3.0-dev-00427-g8b30f22
> > (2009-10-26-13:18)
> >
> > ...
> >
> > I get
> > xsvf processing file: "vhdl/cpld/
+++ David Brownell [2009-10-21 09:49 -0700]:
> On Wednesday 21 October 2009, Wookey wrote:
> > > I'm going to commit this even though I can't test it.
> >
> > I'll test this imminently. SVF/XSVF has been completely broken since
> > r1614 when the s
ate reset lines
+# Override this in the interface config for parallel dongles
+reset_config trst_and_srst separate
+
+# flash bank
+# 29LV650 64Mbit Flash
+flash bank cfi 0x 0x80 2 2 0
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http
+++ Øyvind Harboe [2009-10-26 13:46 +0100]:
> git diff >myfixespostasattachmenttolist.txt
And that needs to be
git diff origin/master > myfixespostasattachmenttolist.patch
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://woo
pository in /openocd/.git/
openocd.git.sourceforge.net[0: 216.34.181.91]: errno=Connection timed out
> git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
> cd openocd
OK. Looks like I'm in business. Cheers for quick response.
Wookey
--
Principal hats:
s david's svf changes in. I'm assuming that the
build process itself hasn't changed at all?
I realise all this is in some flux at the moment, and I'm asking dumb
questions because git scares me, but I don't suppose I'm unusual in
that, and I think some of us are in dang
helps unfortunates using Windows where
usb-driver installation is such a pain, but I'm not convinced for the
Linux libftdi case. Still, it's not my call.
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
___
8
to:
interface ft2232
ft2232_device_desc "Amontec JTAGkey-2"
ft2232_layout jtagkey
ft2232_vid_pid 0x0403 0xcff8
Openocd itself shoulnd't need to change at all.
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
__
+++ David Brownell [2009-10-21 10:05 -0700]:
> On Wednesday 21 October 2009, Wookey wrote:
> > I recently tried using
> > the python (3.0!) converter which allegedly converts 'illegal' xilinx
> > xsvf files into kosher xsvf files, but I still found that all I
ith, or a way of telling it to accept the
ones it accepted up until r1613 (they work just fine, and come
straight out of Xilinx's tools so I find myself skeptical of the 'this
is not valid and shouldn't be allowed' claim).
More soon.
Wooke
D
+#
+#
http://www.marvell.com/products/embedded_processors/developer/kirkwood/openrd.jsp
+#
+
+interface ft2232
+ft2232_layout sheevaplug
+ft2232_vid_pid 0x0403 0x9e90
+ft2232_device_desc "OpenRD JTAGKey FT2232D B"
+jtag_khz 3000
+
--
1.6.3.3
- End forwarded message -
Wookey
-
oot the kernel with the debug
enabled? (It would be very useful).
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
+++ Wookey [2009-10-10 12:33 +0100]:
> +++ Jon Smirl [2009-10-08 17:33 -0400]:
> > Can someone help me out and point me to a working cross toolchain for
> > arm7tdmi with uclibc or equivalent on Linux? I've got a working glib
> > setup but it keeps linking in 900KB of
olchain, not an
actrual built one. There will no doubt be some of those along shortly
but I'm not sure we've got any online.
People - does someone have ready-built toolchains lying about?
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.or
xplaining it in the docs somewhere should make it clear.
This syntax makes it rather easier to have more than one expected-id
too (althogh I still think a better solution there in the medium term
is to specify the components of the ID (vendor/device/stepping) and
allow don't-care bits.
Wookey
but I know almost nothing about git-world.
I've got some more complicated patches to come so pointers to how to
make patches that make your life easy are welcome.
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
_
---
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
tcl so this is
all a bit crufty now, but you get the idea - we have found two valid
TAPID variants - there may be more. If it was split into vendor, part,
stepping (as it normally is in BDSL files) then somethig smarter could
be done.
--- /home/wookey/balloon/openocd/git/tcl/target/pxa270.c
enocd -s utils/openocd -f balloon3-amontec.cfg -f loadloon.cfg -f shutdown.cfg
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
this out.
I have a pile of pending changes for balloon3, xcr3256 and pxa270 which
I just tidied up last night after fixing various annoyances like this
(it works OK for us with this set wrong, but you get a lot of
whinging).
Will send them in shortly.
Wookey
--
Principal hats: iEnd
ood fettle.
> > Working with CPU is very unstable.
> > I use Olimex ARM-USB-OCD, under Linux with libftdi.
Same here. We have found cpu and NOR flash uploading reliable - all
our problems are with CPLD loading and USB getting 'stuck'.
> > I also use patch
I'm using the old 'long' style already?
Are there public xsvf specs I can look at to try and understand what
valid/invalid transitions actually are?
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
__
+++ Wookey [2009-08-19 20:10 +0100]:
> +++ Øyvind Harboe [2009-07-21 22:56 +0200]:
> > On Tue, Jul 21, 2009 at 3:07 PM, Wookey wrote:
> > > +++ David Brownell [2009-07-20 15:53 -0700]:
> > >> On Monday 20 July 2009, Wookey wrote:
> > >> > Error: B
+++ Øyvind Harboe [2009-07-21 22:56 +0200]:
> On Tue, Jul 21, 2009 at 3:07 PM, Wookey wrote:
> > +++ David Brownell [2009-07-20 15:53 -0700]:
> >> On Monday 20 July 2009, Wookey wrote:
> >> > Error: BUG: TAP path doesn't finish in a stable state
is too. I thought it was fixed too.
As it's really quite annoying on pxa (and I have a (vague)
understanding of autotools) I'll try and find out what to
prod. It was still broken back at r1979 but is good in r1609.
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill
cd.
I don't have the actual numbers to hand but can post them when I get
back if this is interesting.
I don't know if this speed-up is to be expected? It is certainly very
welcome.
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebi
+++ David Brownell [2009-07-20 15:53 -0700]:
> On Monday 20 July 2009, Wookey wrote:
> > Error: BUG: TAP path doesn't finish in a stable state
> Looks like r1980 creating jtag_add_statemove() from the XSVF-specific
> code might have seeded this problem ... if later chan
+++ David Brownell [2009-07-20 15:53 -0700]:
> On Monday 20 July 2009, Wookey wrote:
> > Error: BUG: TAP path doesn't finish in a stable state
>
> I'd have thought that was a requirememnt for (X)SVF... it's hard
> to decrypt the binary XSVF,
Which is wh
inx coolrunner xcr3256
#simple device - just configure a tap
jtag newtap xcr tap -irlen 6 -ircapture 0x01 -irmask 0x03 -expected-id
0x0494c093
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
___
Open
so I assume there is some...
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
stitution like SPI
which provides services like keeping money in pools for projects and
legal advice, to Free Software projects. This requires little more
than asking them to accept OpenOCD and set up a pool for project monies.
Having a copyright assignment body might be useful.
Wookey
--
st - that's a benefit you've
had to date. Now it's been noticed (perhaps an understatement!) you
and others will find things slightly less convenient for a while,
until a proper permanent fix is in place. That will happen a lot
quicker if a) this discuession dies down and b) t
ons isn;t going to make any
difference. I suppose you could go right back to Dominic's original,
combined with his statement of implied FTD2XX exception - that might
fly.
Good luck with that. I think you'd be on a hiding to nothing.
Wookey
--
Principal hats: iEndian - Balloonboard
+++ David Brownell [2009-05-22 10:32 -0700]:
> On Friday 22 May 2009, Wookey wrote:
>
> > 1) Is there any agreement that the reset info doesn't really belong in
> > the board file because it depends on the dongle and wiring too, or is
> > that an unusual case?
&
+++ Zach Welch [2009-05-21 15:12 -0700]:
> On Thu, 2009-05-21 at 21:50 +0100, Wookey wrote:
> > +++ Wookey [2009-05-19 12:29 +0100]:
> > > As described on
>
> I like the idea for a base.cfg file, as it allows users to tweak the
> defaults of their installed OpenOCD.
+++ Wookey [2009-05-19 12:29 +0100]:
> As described on
> http://www.balloonboard.org/balloonwiki/Balloon3OpenOCD I have working
> configs for use with the balloon board and Olimex and Amontec JTAG
> dongles. I won't copy them all into this message - look at that page
> f
gles via openOCD to reduce
the amount of config/code maintained?
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
+++ Peter Korsgaard [2009-05-19 13:41 +0200]:
> >>>>> "Wookey" == Wookey writes:
>
> Hi,
>
> Wookey> 1) Is there a way to output a user message? Currently
> Wookey> flash write_image erase kernel/zImageInitrd 0x20 bin
> Wookey> inv
mismatch in SIR
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x58d3 pc: 0x
MMU: disabled, D-Cache: disabled, I-Cache: disabled
(processor reset)
What are the 'requested checks' referred-to? What should I specify
e file specifies a likely default and that is overridden later
in the main config if it's not right for you?
--- /home/wookey/balloon/openocd/svn/trunk/src/target/target/pxa270.cfg
2009-05-13 02:41:22.0 +0100
+++
/home/wookey/balloon/loontest/balloonsvn/trunk/utils/openocd/r140
e-minded manner to work with old-fashion parallel dongles?
Perhaps emitting a 'hit reset manually' message? Would that help?
If there is then I'll finish adding support for the lart/jtux device
and send it in, but currently I'm stuck.
Wookey
--
Principal hats: iEndian -
52 matches
Mail list logo
