John,
>
> The following patch adds support for DMA mode access as
> supported by EJTAG 1.0/2.0 processors, specifically the
> Broadcom BCM5352 (and BCM47xx) SoC processors used in the
> Linksys WRT54G series of wireless routers.
> This is needed because PrAcc mode seems non-functional on
> th
On Mon, 2008-10-06 at 21:37 -0400, Duane Ellis wrote:
> Michael Schwingen wrote:
> > The C code reads its parameters directly from params, and writes its result
> > there.
> Agreed, sounds simple. But I do not think "code-lets" is the right idea.
> It is too simplistic.
>
> Reasoning:
I was th
Hi,
I have researched in the list archives and have seen some attempts to get MX31
support under OpenOCD.
Has anyone succesfully used OpenOCD with MX31 processor? If so, which JTAG
hardware have you used?
Thanks,
Fabio Estevam
___
Openocd-d
Michael Schwingen wrote:
>> Now the question is: can we generate position-independent code using
gcc on all platforms?
But remember, today OpenOCD supports exactly 2 targets: ARM and MIPS
(sort of).
For ARM, this is simple. In C - might be tough to coax the compiler into
working the way you
Michael Schwingen wrote:
> The C code reads its parameters directly from params, and writes its result
> there.
Agreed, sounds simple. But I do not think "code-lets" is the right idea.
It is too simplistic.
Reasoning:
Most "flash sequences" are simplistic, there are no more then 10 to 20
comm
Øyvind Harboe wrote:
> There is an objloader in eCos w/a suitable license model.
> But perhaps we can do position independent code on all targets w/GCC?
>
If it requires a "obj loader" we have made something to complex.
-Duane.
___
Openocd-developmen
Michael Schwingen wrote:
> First, I think the target code should stay as small as possible, because
> there may be targets where very little RAM is available for the code.
>
I disagree, I think we always have 4K of ram, here's why:
Generally:
There are two classes of devices.
1) Thos
Hi,
this patch add an interface definition for the Embedded-Projects OpenOCD
USB JTAG programmer/debugger.
Enjoy,
John McCarthy.
Date: Sun, 5 Oct 2008 23:19:11 -0400
Subject: [PATCH] Add interface config for the Embedded-Projects OpenOCD-USB
JTAG programmer.
Signed-off-by: John McCarthy <[EMAI
Hi,
The following patch adds support for DMA mode access as supported by EJTAG
1.0/2.0 processors, specifically
the Broadcom BCM5352 (and BCM47xx) SoC processors used in the Linksys WRT54G
series of wireless routers.
This is needed because PrAcc mode seems non-functional on these chips. I have
duane> (A) Take a page from the "arm-semi-hosting".
oyvind> [snip] What's "arm-semi-hosting"?
Also see this:
http://www.arm.com/support/faqdev/1494.html
ARM defined a specific "SWI" instruction & SWI number that allow the
debugger to communicate with the host system via the debugger.
Sup
John McCarthy wrote:
> Hi,
>
> has anyone got OpenOCD working with a Faraday FA526 processor (actually
> a Raritan Kira100 which uses a FA526 processor)? It appears to be an
> ARM926 variant but apparently not exactly. Does this require target
> specific support or am I just missing some configur
somebody> I'm not convinced that your JTAG chain is configured correctly
somebody> or that your JTAG interface is able to communicate with the
device.
somebody> ARM11 is finicky
I believe this is exactly the ARM 1176 chip.
Here is why.
> Info: JTAG device found: 0x2b900f0f (Manufacturer: 0x78
On Mon, Oct 6, 2008 at 9:42 PM, Øyvind Harboe <[EMAIL PROTECTED]> wrote:
> What version of GDB are you using?
GNU gdb (Sourcery G++ Lite 2008q1-126) 6.7.50.20080107-cvs
I tracked down the problem slightly more.
The problem is the arm_write_pc (struct regcache *regcache, CORE_ADDR
pc) (arm-tdep.c,
Øyvind Harboe wrote:
>> - fixup/relocate the code for the target address where it is used.
>
> There is an objloader in eCos w/a suitable license model.
>
> But perhaps we can do position independent code on all targets w/GCC?
That would be great - at least for a start.
We can decide what to d
> I've used the same device successfully with a mips_m4k processor.
Nice! :-)
> The halt command returns 'BUG: unknown debug reason: 0x0' but the
> processor is halted. The reset command does reset.
This appears *after* arm7_9_poll() has failed, so I'm thinking it is just
a followup error.
Per
Hi,
has anyone got OpenOCD working with a Faraday FA526 processor (actually
a Raritan Kira100 which uses a FA526 processor)? It appears to be an
ARM926 variant but apparently not exactly. Does this require target
specific support or am I just missing some configuration?
I'm using an OpenOCD USB
I believe I see something similar/the same problem.
What version of GDB are you using?
(I'm using 6.8 from http://www.zylin.com/gccbinary.html)
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
Free eCos workshop in Oslo October 21!
ht
> - fixup/relocate the code for the target address where it is used.
There is an objloader in eCos w/a suitable license model.
But perhaps we can do position independent code on all targets w/GCC?
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash
Duane Ellis wrote:
> Oyvind/Georg,
>
> I see you both are talking about the flash algorithm support in openocd.
>
> There is a few tricks that I see that could be done to simplify the
> situation.
>
> To communicate with a "flash driver" - first - do not call it a flash
> driver.
> Call it an
Hi
I am just guessing here but it can an issue with the timing of the AHB
bus and running from flash at 50MHz.
The SWLDP overrun is received through the JTAG interface, so it seems
JTAG is working.
SWDLP overruns are not JTAG problems, they are when the debug unit on th
CM3 receives
debug comm
On Mon, Oct 6, 2008 at 8:24 PM, Spen <[EMAIL PROTECTED]> wrote:
>> >> I'm not too familiar with that code or the problem
>> w/PLL/clocks that
>> >> you are seing, but I modified it to wait 1000ms rather
>> than try 100
>> >> times...
>> >>
>> >> Seems a tad more robust to me.
>> >>
>> >
>
> This is
> >> I'm not too familiar with that code or the problem
> w/PLL/clocks that
> >> you are seing, but I modified it to wait 1000ms rather
> than try 100
> >> times...
> >>
> >> Seems a tad more robust to me.
> >>
> >
This is way too long a timeout.
Probably 50ms-100ms is more suitable, otherwise
On Mon, Oct 06, 2008 at 12:59:33PM +0100, Ben Dooks wrote:
> Info: JTAG device found: 0x00eb509d (Manufacturer: 0x04e, Part: 0x0eb5,
> Version: 0x0)
> Error: 'arm11 target' JTAG communication error SCREG SCAN OUT 0x00 (expected
> 0x10)
> Does anyone have any ideas on what is going wrong?
Do
Centralize error handling for buggy register handling
Committed.
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/register.c
===
--- src/target/register.c (revision 1012)
+++ src/target/register.c (working c
On Tue, Sep 02, 2008 at 08:54:20PM +0800, Ray Tang wrote:
> Hi,
>
> I use S3C6400 cpu of ARM1176 core and use insight to debug.
> when I set breakpoint at 0x500c and execute continue command,though
> I telnet to OpenOCD use reg command display pc register value is
> 0x500c,but receive erro
On Thu, Oct 02, 2008 at 08:50:32AM +0200, ?yvind Harboe wrote:
> On Wed, Oct 1, 2008 at 11:08 PM, Ben Dooks <[EMAIL PROTECTED]> wrote:
> > Has openocd been tested recently with ARM1176? I'm running r1013
> > and it is repsonding as so:
> >
> > Info: JTAG device found: 0x2b900f0f (Manufacturer: 0x
26 matches
Mail list logo
