On Thursday 14 January 2010, richard vegh wrote:
> here it is a patch for
> that crash for file lpc3180.c.
> It contains these corrections:
> -Crash and related functionality
> -some debug message
> -Command handling now works
After minor cleanups, I committed this and now it's in mainline.
So, ca
On Sunday 10 January 2010, richard vegh wrote:
> Unfortunately I don't use git.
You don't need to use "git" to create usable patches. If
two trees are clean,
diff -NaurP tree1 tree2
will generate a better patch. (And if they're not clean,
it's mostly a case of trimming down the "diff"
It's easy, try this:
git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
patch -p1 < filename.patch
git diff > gitpatch
--
Øyvind Harboe
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 fl
Unfortunately I don't use git.
Isn't it possible that you apply the changes with simple "patch -p1 <
filname.patch" on your working copy, then make a diff or commit it? The
lpc3180.c has the only file what has changed and 3 new files are added.
Richard
On Sun, Jan 10, 2010 at 8:27 PM, Øyvind Harb
"Is there a chance you could use "git diff"? I don't know if I'll
be able to apply and review this patch easily tomorrow...
--
Øyvind Harboe
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 program
Patch for:
- large page nand flash crash
- lpc3180 driver correction to accept lpc3180 select 0 mlc|slc commands
- 3 config files to support hitex lpc3250 usb stick
Hopefully it can be merged before 0.4.0 release.
Is this patch OK for you?
Richard
On Fri, Jan 8, 2010 at 10:38 AM, richard vegh
I will provide one if it works reliably.
Anyway do you know why there is so big timing differences accessing large
page nand flash with slc or mlc mode?
With mlc mode accessing is fast:
> lpc3180 select 0 mlc
mlc controller selected
> nand probe 0
NAND flash device 'NAND 128MiB 3,3V 8-bit' found
On Thursday 07 January 2010, richard vegh wrote:
> GDB. Now I guess I have found one problem.
>
> In lpc3180c line 519 allocates memory:
> oob_buffer = malloc(6);
> But later set more then allocated at line 562:
> memset(oob_buffer, 0xff, (nand->page_size == 512) ? 6 : 24);
> a
Could you provide a patch?
--
Øyvind Harboe
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
Openocd-de
I had recompiled the nand flash driver with -O0 to be able better debug with
GDB. Now I guess I have found one problem.
In lpc3180c line 519 allocates memory:
oob_buffer = malloc(6);
But later set more then allocated at line 562:
memset(oob_buffer, 0xff, (nand->page_size == 512
On Wed, Jan 6, 2010 at 11:43 AM, richard vegh wrote:
>>I think you should focus on getting the gdb symbols for the bt ...
>
> I would happy if I can use symbols with my own built one. Do you have any
> hints why gdb can not use the already available symbols in the executable?
I don't know... it s
>I think you should focus on getting the gdb symbols for the bt ...
I would happy if I can use symbols with my own built one. Do you have any
hints why gdb can not use the already available symbols in the executable?
Anyway the crash is present in 0.3.1 also so I think the latest one also
contain
> How should I change the configuration?
It was worth a try. I think you should focus on getting the gdb symbols for the
bt to work using latest from git, that will point us to the culprit I think.
> I will separate the config file after everything is working. I think it is
> not a problem to hav
I have tried with dummy interface. I have just replaced the previous config
file beginings with these lines:
interface dummy
#ft2232_device_desc "LPC3250-Stick"
#ft2232_layout stm32stick
#ft2232_layout comstick
#ft2232_layout usbjtag
#ft2232_layout jtagkey
#ft2232_layout olimex-jtag
#ft2232_vid
I have checked that the executable contains the symbols:
objdumps --syms ./openocd
prints out thousands of lines. Then how to enable gdb to use that info as I
invoked like this:
debian:/usr/src/openocd040rc1/openocd/src# gdb -se=./openocd --args
./openocd -f proba.cfg -d 3 -l logNandWrCrash3.log
Also, could you split your configuration file in three files:
- interface
- target
- board
I would like to see all three contributed to the openocd target library.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScal
On Tuesday 05 January 2010, richard vegh wrote:
> #0 0xb805a416 in __kernel_vsyscall ()
> No symbol table info available.
This trace isn't helpful if you haven't included
the symbol table in your OpenOCD build.
The most immediately useful thing you can do is
send along a backtrace which includes
Another thing would be to step through the nand write code
using GDB to try to get to the crash from that end. The backtrace
wasn't very helpful.
Also trying git master head would be good.
If this is a memory corruption, then the crash could be *after* the bug.
Another way to bisect is then to d
Can you make it crash using the dummy driver?
configure --enable-dumy
openocd ... -f interface/dummy.cfg ...
--
Øyvind Harboe
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
__
19 matches
Mail list logo
