Here is a patch to fix a startup in C100 (arm1136). Basically make sure
that UART is configured before using it.
Michal
diff --git a/tcl/target/c100helper.tcl b/tcl/target/c100helper.tcl
index 477fe5c..2a12c36 100644
--- a/tcl/target/c100helper.tcl
+++ b/tcl/target/c100helper.tcl
@@ -469,11 +469,
Attached is the patch to get arm11 on telo scripts working again with
the latest openocd code.
I also included a patch for fixing adapter_nsrst_assert_width. Without
it, I can't really use srst signal.
Michal
On Thu, 2010-04-22 at 07:20 +0200, Øyvind Harboe wrote:
> On Thu, Apr 22, 2010 at 4:19
hip before the u-boot code
[that causes later the data fault when flash write] executes.
One possibility is that 'flash write+memwrite code' leaves some state
altered and that somehow interacts with u-boot and causes the problem
described below. Unfortunately, I don't know enough ab
Here is updated patch.
Michal
diff --git a/doc/openocd.texi b/doc/openocd.texi
index 5273d5d..cfba79f 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -5671,10 +5671,20 @@ separately.
@end deffn
@anchor{load_image}
-...@deffn Command {load_image} filename address [...@option{bin}|@opt
Here is the patch for openocd.texi for load_image as requested.
Michal
On Wed, 2010-04-14 at 07:40 +0200, Øyvind Harboe wrote:
> > Perhaps adding this to openocd docs will help others.
> > I would think that adding a command
> > 'load_image_bin filename address length file_offset' would be helpful
Øyvind,
Here is the current help on load_image (from the openocd website).
>>Command: load_image filename address [bin|ihex|elf]
Load image from file filename to target memory at address. The
file format may optionally be specified (bin, ihex, or elf)
And here are some of
It seems that arm11 in openocd is broken.
1. mrc/mcr are not working (try executing mcr/mrc commands in
c100helper.tcl).
2. memwrite burst is not working, see log below. Looks like a data fault
during execution. When memwrite burst works it gives DSCR=6006, when it
is broken DSCR=605a. This bug
Here is a patch that adds file_offset to load_image command.
This allows loading 'bin' regions that do not start at 0x0 file offset.
I use this to create a simple flash driver in tcl. It load chunks of the
bin file to memory and burn them to flash. This is saved me a quite a
bit of time as I did
> version
Open On-Chip Debugger 0.5.0-dev-00139-ga092e8d (2010-03-26-10:20)
> arm966e cp15 0
0: 0955b700
> arm mrc 15 0 0 0 0
arm966e doesn't implement MRC
Michal
On Fri, 2010-03-26 at 07:19 +0100, Øyvind Harboe wrote:
> On Fri, Mar 26, 2010 at 4:46 AM, michal
Have anyone tried using cp15 command on arm9 recently? Here is my
attempt:
mww 0x0030 0xee100f10
armv4_5 disassemble 0x0030
>0x0030 0xee100f10 MRC p15, 0x00, r0, c0, c0, 0x00
reg pc 0x0030
step
reg r0
>r0 (/32): 0x41059680
# implementor: 0x41
# architecture: 0x05 (ARM
ncy problem - workaround - solution (David Brownell)
>3. Re: ST-Link with OpenOCD? (simon qian)
>4. load_image question (michal smulski)
>5. Re: load_image question (Freddie Chopin)
>6. Re: xds100v2 (Michael Schwingen)
>7. [SWD] STM32Primer2 JTAG/SWD + RLink pinout +
Hi,
I have an ARM IC with internal flash (512kbytes) and sram (64kbytes). I
am trying to write flash via jtag. The idea is to split the image into
64kb chunks and upload them via jtag one at a time to internal SRAM;
then burn to flash.
However, I can't seem to find an appropriate openocd command t
Here is a set of commands that reproduces my problem.
While I agree with David about -c and -f bug, this is a different one.
# Ubuntu 9.04
git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
cd ./openocd
./bootstrap
./configure --enable-maintainer-mode --enable-dummy
make
cd src
#
The same sequence works on my arm1136. However, when you put a scope to
SRST signal you will find out that it is actually high (ie not
asserted). At least this is what I found on my setup (with olimex)
On Tue, 2009-10-13 at 23:07 -0700, David Brownell wrote:
> On Tuesday 13 October 2009, mic
Updated to the latest (git describe):
0.2.0-387-g3b95d0e
No difference in the behavior.
I did notice that if I run this:
proc jtag_init {} {
jtag arp_init-reset
}
It works (ie, initial scan chain works).
However this:
proc jtag_init {} {
#Make sure we reset the hardware before we talk
I attached telo.cfg that I used for testing with the dummy driver.
'hangs.log' is with the reset_init and nohang.log is with that procedure
removed.
It looks like the openocd does not hang but rather skips the initial
scan when reset_init exits. The result is similar to the user as I can't
access
How do I add 'dummy' interface to openocd?
$ ./openocd -c "interface dummy"
Open On-Chip Debugger 0.3.0-dev-00355-g9aab763 (2009-10-12-14:15)
$URL$
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Error: The specified JTAG interface was not found (dummy)
The following
I tried to use jtag_init {} but it freezes my system (arm11).
openocd recognizes my jtag dongle but it does not show jtag chain.
If jtag_init {} is empty, openocd works. As soon as I put something
there (such as 'puts 'hello world') it freezes.
I am running at this revision:
commit 9aab763fa555f0
arm11 has a bug in that you cannot at the same time assert srst to the
arm11 core and access its JTAG logic. Asserting srst will disable TAP
logic.
My guess is that flops' reset pin in JTAG core are connected to srst.
It is unclear to me how long you have to wait after reset before
accessing JT
Here is the patch on jtag_reset_on_init (again).
This fixes the problem with Olimex dongle (on power-on it drives srst
low) but will also fix libftd2xx.so library (asserts srst for > 250ms).
On Thu, 2009-10-01 at 07:32 +0200, Øyvind Harboe wrote:
> > 1. put reset_on_init patch that I submitted
There is one more problem with reset handling during init. for ft2232
chips [at least on Olimex dongle].
When you first plug-in the Olimex dongle to USB port it drives srst
signal low. This cause failure (see output below) during initial openocd
JTAG scan. It only fails on the first try. All later
Updates that make the reset work on these boards. Please update to the
svn tree.
# board(-config) specfic parameters file.
# set CFG_REFCLKFREQ [configC100 CFG_REFCLKFREQ]
proc config {label} {
return [dict get [configC100] $label ]
}
# show the value for the param. with label
proc showco
I confirm that, with those fixes in ft2232, openocd no longer locks-up
with libftdi (checked on rev.2767). Also libftdi does not touch srst or
trst so I will be switching to that library.
What would it take to get the reset width config into the main svn tree?
jtag_nsrst_assert_width
jtag_ntrst_as
This patch (it includes Øyvind's previous patch) fixes my problems with
reset. By default it will do nothing so it should not affect anybody.
I added [optional] reset before running jtag_init_inner().
Is there a chance to commit this to svn tree?
--Michal
On Thu, 2009-09-24 at 00:28 +0200, Mich
Most of the cheap ft2232 devices probably do not have sense circuit on
SRST. Actually, I would like to have Vcc sense circuit on my Olimex
board but it is a different topic.
For most users, it is enough to be able to call reset routine defined by
reset_config. It most cases (I think) the user will
On Tue, 2009-09-22 at 17:59 -0700, David Brownell wrote:
> On Tuesday 22 September 2009, michal smulski wrote:
> > The offending code is called from this function:
> > static int ft2232_init_ftd2xx(uint16_t vid, uint16_t pid, int more, int*
> > try_more)
> >
> >
se
or something similar.
On Wed, 2009-09-23 at 07:26 +0200, Øyvind Harboe wrote:
> On Wed, Sep 23, 2009 at 1:30 AM, michal smulski
> wrote:
> >
> > The offending code is called from this function:
> > static int ft2232_init_ftd2xx(uint16_t vid, uint16_t pid, int more, i
The offending code is called from this function:
static int ft2232_init_ftd2xx(uint16_t vid, uint16_t pid, int more, int*
try_more)
And the actual function call is here:
status = FT_OpenEx(openex_string, openex_flags, &ftdih);
ftd2xx is a closed source library. However, openocd should not rely o
I checked out r2726 and applied the patch. It works great during 'reset
halt/init/run/etc' but again does not do anything for initial JTAG scan.
I hooked up scope to the srst and trst to see how the jtag controller
drives those signals.
For the initial reset (before first JTAG scan) I get about 1
I wonder why that bug does not show on arm1136 on my system and breaks
for other people (i.MX35)?
On Fri, 2009-09-18 at 13:28 +0200, Øyvind Harboe wrote:
> > Any suggestions?
>
> The problem has to do with end state.
>
> In 2046 there was a global variable that subtly tracked
> what the end s
Neither of these methods apply to the initial jtag scan. At least not on
olimex dongle that I use.
I added this to my config
$_TARGETNAME configure -event reset-assert-post {
puts "Assering reset"
sleep 1
}
This does not get executed on the inital jtag scan:
Info : Disabled memory write
Here is a patch against r2715 that makes the arm11 memwrite burst work
again with Olimex JTAG.
As far I can see in the code, the original ft2232_add_pathmove()
function was split into two ft2232_add_pathmove & clock_tms(). I think
that clock_tms() is working ok as it is used elsewhere. So the bug
'tms_sequence long' is not a valid command on r1824 or r1825. On r2709
produces error during burst write.
Is there anything else I can try?
--Michal
On Tue, 2009-09-15 at 09:55 +0200, Magnus Lundin wrote:
> Øyvind Harboe wrote:
> > On Tue, Sep 15, 2009 at 6:18 AM, michal
If you are modifying srst behavior can you add functionality so that I
can define how long is the srst reset as well as how long after srst
pulse JTAG controller waits before initiating scan?
On Mon, 2009-09-14 at 20:35 +0200, Øyvind Harboe wrote:
> On Mon, Sep 14, 2009 at 7:42 PM, David Brownel
> Did you also double check that 1822 breaks?
>
r1822 is broken without any mods. I did not try adding usleep() here but
double-checked that it fails on memburst.
> The burst code is executing two instructions to increment the pointer. Perhaps
> the second instruction is getting executed twic
It does seem that this is a timing issue. However adding various
usleep() around jtag.c and arm11_dbtap.c file does not produce errors on
r1817. Also increasing TAP_IDLE's does not break the code.
It might be more productive to capture some of the data going to ft2232
interface. Is there a simple
Ok,
Here is the script I run on various builds (svn 1504 - 1900)
init
halt
reset init
memwrite burst enable
load_image ./images/test.bin 0x8000 bin
verify_image ./images/test.bin 0x8000 bin
exit
Here are some results:
# svn 1600
#downloaded 88 byte in 0.008575s
#verified 88 bytes in 0.
No, the addresses with 0x0 do not get touched/written. I tested this by
first writing 'beefcafe' to all DDR2 memory addresses and then loading
image 'load_image' The 'beefcafe' was there on every other address like
0x0 in the previous test.
Michal
On Sat, 2009-09-12 at 10:53 +0200, Øyvind Harboe w
ep 11, 2009 at 8:22 AM, Øyvind Harboe
> wrote:
> > On Fri, Sep 11, 2009 at 6:54 AM, michal smulski
> > wrote:
> >>
> >> Attached:
> >> 1. debug output for load_image without and with memburst write on
> >> arm1136. See the slow load time on
I can see there is run_algorithm implemented in arm11.c. Can you give me
some pointers on what needs to be added/changed? I can take a stab at
this.
Note that I see a really slow times for coping uboot to DDR memory
(load_image). Is this expected as well?
If I turn on burst writes, things go mu
When I run this code:
set CONFIG_SYS_HZ_CLOCK16500
global CONFIG_SYS_HZ_CLOCK
proc showAmbaPLL {} {
global CONFIG_SYS_HZ_CLOCK
puts [format "CONFIG_SYS_HZ_CLOCK %d" $CONFIG_SYS_HZ_CLOCK]
}
I get this message:
Runtime error, file "t.tcl", line 198:
can't read "
I have a couple questions about tcl:
1. How do you make variables defined as global (see c100regs.tcl &
c100helper.tcl) visible in procedures? I would like to reuse defines in
c100regs.tcl. Otherwise, I need to define them every time I want to use
them. I tried 'global' but it does not work.
2. H
AM, michal smulski
> wrote:
> >
> > When I erase flash from which arm11 boot, I can no longer attach to JTAG
> > port of the the arm11. I can still scan-out the the two cores but then
> > jtag_validate_chain() reports errors (see debug output).
> >
> > With a
Hi,
I attached the config files that I use to setup openocd. It would be
great if they made into openocd svn tree.
The big problem with openocd & c100 right now is that I can't use it
when the boot sector (NOR 1st sector) is blank. openocd scans the JTAG
chain and correctly detects both ARM11 cor
When I erase flash from which arm11 boot, I can no longer attach to JTAG
port of the the arm11. I can still scan-out the the two cores but then
jtag_validate_chain() reports errors (see debug output).
With a valid image (that basically set plls, ddr, not etc.) I can attach
to the arm11 via JTAG.
And here is the bug to get 'flash probe 0' working (arm11.c,
arm11_write_memory():
-memcpy(&value, buffer + count * sizeof(uint16_t), sizeof(uint16_t));
+memcpy(&value, buffer + i * sizeof(uint16_t), sizeof(uint16_t));
--Michal
On Tue, 2009-08-04 at 11:06 -0700, michal sm
The bug is as follows (arm11.c):
-memcpy(buffer + count * sizeof(uint16_t), &svalue, sizeof(uint16_t));
+memcpy(buffer + i * sizeof(uint16_t), &svalue, sizeof(uint16_t));
--Michal
On Mon, 2009-08-03 at 15:45 -0700, michal smulski wrote:
> Little-endian mode. I can correctly acces
Attached is my config file.
--Michal
On Tue, 2009-08-04 at 00:08 +0200, Michael Schwingen wrote:
> michal smulski wrote:
> > I am using C100 (Mindspeed ARM11 dual core). I can correctly access
> > DDR2 and 16 bit flash on it via 8-bit and 32-bit commands (mdb,mdw) but
> >
I am using C100 (Mindspeed ARM11 dual core). I can correctly access
DDR2 and 16 bit flash on it via 8-bit and 32-bit commands (mdb,mdw) but
not 16-bit access.
I discovered this by trying to do 'flash probe 0' and it returned 0. I
then looked through code and noticed that flash control/info is ac
49 matches
Mail list logo
