Re: [Openocd-development] NAND: add erase_page callback

[Marek Vasut]

Dne Po 14. prosince 2009 21:55:25 David Brownell napsal(a):
> On Monday 14 December 2009, Marek Vasut wrote:
> > Dne Po 14. prosince 2009 02:46:26 David Brownell napsal(a):
> > > On Sunday 13 December 2009, Marek Vasut wrote:
> > > > I'd send followup patch that'd clean that mess up altogether ... it's
> > > > cleaner and much easier to track back in git log.
> > >
> > > Go for it then.  :)
> >
> > Merge the erase patch then. :)
> 
> Not till I see that followup patch ... ;)
> 
Actually btw. what's your idea here? I kind-of lost track ...
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Cross Platform Debugger

[René Doss]

Hi,
you should also have a look at codeblocks. This IDE look nice and
useful. I had not used as cross development/debugging tool, but I should
be simple possible.

http://www.codeblocks.org/

Rene


Am 13.12.2009 22:12, schrieb Carsten Breuer:
> Hi Michael, hi all
>
>   
>> There is setedit that uses gdb. I haven't tried the one on windows
>> 
> Cool :-). Looks like Borland C++ 3.1, that i have used
> some decades ago with DOS 5.0 :-))). Since i use midnight commander
> a lot, this is really an option :-).
>
>   
>>> kdbg would be nicer. insight sucks. If someone would come up with
>>>   
>> something that looks like IAR or Raisonnance that'd be neat. I'm
>> looking into that but right now I am too busy with my porting of STM8
>> to GCC.
>> 
> Well, i would be happy with KDbg and OpenOcd.
>
>   
>> IAR could but it is expensive. At work I paid around $6000 for it. It
>> costs about $1500 per year for support.
>> 

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problem when tryng to flash LPC2368

[Marcelo Utikawa da Fonseca]

Hi again!

I am still having problems to write the flahs in  an LPC2368.

Now I know that the first 64 bytes is never erased. There is always data 
in this area. 95% of the write errors are caused because the data is not 
correctly programmed in this area.
In the J-Flash software, this area have data after a erase so I think 
that the data in this area is correct.
I am using J-Link in both OpenOCD and J-Flash. I have tried a programmer 
derivated from axm0432 and I receive the same results...

Could this be a bug in OpenOCD? It cannot write in this situation but 
J-Flash can so the problem is not in the hardware or the programmer 
because they are the same.

Best regards,
Marcelo Utikawa da Fonseca

Marcelo Utikawa da Fonseca escreveu:
> Hi!
>
> First of all, I am new to this list.
> My name is Marcelo Fonseca. I work in a Brazilian design house and have 
> experience with LPC21xx and LPC23xx from NXP and i.MX family from Freescale.
>
>
> I am having problems to write an LPC2368 with our custom board.
> I can write it with a J-Link and J-Flash software from Segger.
> In OpenOCD all seems to work but many times there are errors when trying 
> to write the flash memory using the GDB.
> If I run a erase in the J-Flash software I have no error and OpenOCD 
> succesfully write to the flash memory.
> When I run the "flash erase_sector" command in OpenOCD, J-Flash says 
> that the flash is blank but I need to run a erase in J-Flash to write 
> the flash using OpenOCD.
> PS.: sometimes I can write in OpenOCD without having to run a erase in 
> J-Flash...
>
> Can anyone help me to solve this issue?
>
> Logs:
>
> Starting OpenOCD:
>
> $ sudo openocd -f jtec.cfg -f lpc2368.cfg
> [sudo] password for utikawa:
> Open On-Chip Debugger 0.2.0 (2009-12-14-11:51) Release
> $URL: 
> http://svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.2.0/src/openocd.c 
> $
> For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
> 100 kHz
> jtag_nsrst_delay: 100
> jtag_ntrst_delay: 100
> Info : device: 4
> Info : deviceID: 67330064
> Info : SerialNumber: S6
> Info : Description: Dual RS232 A
> Info : JTAG tap: lpc2368.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, 
> part: 0xf1f0, ver: 0x4)
> Info : JTAG Tap/device matched
> Warn : EmbeddedICE version 7 detected, EmbeddedICE handling might be broken
>
> Starting GDB without run erase in J-Flash:
>
> arm-elf-gdb -x gdbinit_minilpc.conf
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf".
> Setting up for the Tecnequip MiniLPC.
> The target is assumed to be little endian
> The target may not be able to correctly handle a memory-write-packet-size
> of 1024 bytes. Change the packet size? (y or n) [answered Y; input not 
> from terminal]
> 0x1a04 in ?? ()
> Loading section startup, size 0x204 lma 0x0
> Loading section text, size 0x106f0 lma 0x204
> Loading section .data, size 0x878 lma 0x108f4
> Start address 0x0, load size 69996
> Transfer rate: 3 KB/sec, 972 bytes/write.
> Breakpoint 1 at 0x234
> Note: automatically using hardware breakpoints for read-only addresses.
>
> It never reaches main().
>
> Starting GDB after a erase in J-Flash:
>
> arm-elf-gdb -x gdbinit_minilpc.conf
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf".
> Setting up for the Tecnequip MiniLPC.
> The target is assumed to be little endian
> The target may not be able to correctly handle a memory-write-packet-size
> of 1024 bytes. Change the packet size? (y or n) [answered Y; input not 
> from terminal]
> 0x7fffe152 in ?? ()
> Loading section startup, size 0x204 lma 0x0
> Loading section text, size 0x106f0 lma 0x204
> Loading section .data, size 0x878 lma 0x108f4
> Start address 0x0, load size 69996
> Transfer rate: 3 KB/sec, 972 bytes/write.
> Breakpoint 1 at 0x234
> Note: automatically using hardware breakpoints for read-only addresses.
>
> Breakpoint 1, 0x0234 in main ()
> (MiniLPC)
>
>
> Best regards,
> Marcelo Utikawa da Fonseca
>
>
> -
> Tecnequip Tecnologia em Equipamentos
> Endereço/Address: R. Ganges, 557
> Cidade/City: São Paulo
> Estado/State: SP
> País/Country: Brasil
> CEP/Postal Code: 03445-030
> Fone/Phone: 55-11-20937199
> FAX: 55-11-29412289
> ___
> Openocd-development mailing list
> Openocd-devel

Re: [Openocd-development] Problem when tryng to flash LPC2368

[Nico Coesel]

The first 64 bytes must always be erased. Try to use flashmagic instead of 
OpenOCD. 

These controllers use flash with ECC therefore you cannot program the flash 
partially / patch single bytes.

Nico Coesel


> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Marcelo Utikawa da
> Fonseca
> Sent: woensdag 16 december 2009 13:54
> To: openocd-development@lists.berlios.de
> Subject: Re: [Openocd-development] Problem when tryng to flash LPC2368
> 
> Hi again!
> 
> I am still having problems to write the flahs in  an LPC2368.
> 
> Now I know that the first 64 bytes is never erased. There is always data
> in this area. 95% of the write errors are caused because the data is not
> correctly programmed in this area.
> In the J-Flash software, this area have data after a erase so I think
> that the data in this area is correct.
> I am using J-Link in both OpenOCD and J-Flash. I have tried a programmer
> derivated from axm0432 and I receive the same results...
> 
> Could this be a bug in OpenOCD? It cannot write in this situation but
> J-Flash can so the problem is not in the hardware or the programmer
> because they are the same.
> 
> Best regards,
> Marcelo Utikawa da Fonseca
> 
> Marcelo Utikawa da Fonseca escreveu:
> > Hi!
> >
> > First of all, I am new to this list.
> > My name is Marcelo Fonseca. I work in a Brazilian design house and have
> > experience with LPC21xx and LPC23xx from NXP and i.MX family from
> Freescale.
> >
> >
> > I am having problems to write an LPC2368 with our custom board.
> > I can write it with a J-Link and J-Flash software from Segger.
> > In OpenOCD all seems to work but many times there are errors when trying
> > to write the flash memory using the GDB.
> > If I run a erase in the J-Flash software I have no error and OpenOCD
> > succesfully write to the flash memory.
> > When I run the "flash erase_sector" command in OpenOCD, J-Flash says
> > that the flash is blank but I need to run a erase in J-Flash to write
> > the flash using OpenOCD.
> > PS.: sometimes I can write in OpenOCD without having to run a erase in
> > J-Flash...
> >
> > Can anyone help me to solve this issue?
> >
> > Logs:
> >
> > Starting OpenOCD:
> >
> > $ sudo openocd -f jtec.cfg -f lpc2368.cfg
> > [sudo] password for utikawa:
> > Open On-Chip Debugger 0.2.0 (2009-12-14-11:51) Release
> > $URL:
> > http://svn.berlios.de/svnroot/repos/openocd/tags/openocd-
> 0.2.0/src/openocd.c
> > $
> > For bug reports, read
> http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
> > 100 kHz
> > jtag_nsrst_delay: 100
> > jtag_ntrst_delay: 100
> > Info : device: 4
> > Info : deviceID: 67330064
> > Info : SerialNumber: S6
> > Info : Description: Dual RS232 A
> > Info : JTAG tap: lpc2368.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787,
> > part: 0xf1f0, ver: 0x4)
> > Info : JTAG Tap/device matched
> > Warn : EmbeddedICE version 7 detected, EmbeddedICE handling might be
> broken
> >
> > Starting GDB without run erase in J-Flash:
> >
> > arm-elf-gdb -x gdbinit_minilpc.conf
> > GNU gdb 6.8
> > Copyright (C) 2008 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> > 
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> > and "show warranty" for details.
> > This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf".
> > Setting up for the Tecnequip MiniLPC.
> > The target is assumed to be little endian
> > The target may not be able to correctly handle a memory-write-packet-size
> > of 1024 bytes. Change the packet size? (y or n) [answered Y; input not
> > from terminal]
> > 0x1a04 in ?? ()
> > Loading section startup, size 0x204 lma 0x0
> > Loading section text, size 0x106f0 lma 0x204
> > Loading section .data, size 0x878 lma 0x108f4
> > Start address 0x0, load size 69996
> > Transfer rate: 3 KB/sec, 972 bytes/write.
> > Breakpoint 1 at 0x234
> > Note: automatically using hardware breakpoints for read-only addresses.
> >
> > It never reaches main().
> >
> > Starting GDB after a erase in J-Flash:
> >
> > arm-elf-gdb -x gdbinit_minilpc.conf
> > GNU gdb 6.8
> > Copyright (C) 2008 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> > 
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> > and "show warranty" for details.
> > This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf".
> > Setting up for the Tecnequip MiniLPC.
> > The target is assumed to be little endian
> > The target may not be able to correctly handle a memory-write-packet-size
> > of 1024 bytes. Change the packet size? (y or n) [answered Y; input not
> > from terminal]
> > 0x7fffe152 in ?? ()
> > Loading section startup, size 0x2

[Openocd-development] Codecheck

[Carsten Breuer]

Hi all,


i have done a first quick test with lint over the
OpenOcd-Sources (based on commit 74ce435d97ca4f6f81645d755d04123f075aa42b)
from today.

Lint report a truckload of problems.

The first thing i had to learn was, that it is verry uncommon
in OpenOCD to check the result of malloc. 

Here is a quick list of only a handfull of files
that don't check the result of malloc against NULL. 
(L stands for line):

mflash.c: L 352 
nand/core.c: L501, L616, 653
fileio.c: L83, L98
lpc3180.c: L53, L518, L519, L652, L653, L657, L658
aduc702x.c: L57, L77
at91sam7c: L536, L539, L555, L642, L738, L789, L792, L808, L876
arvf.c: L193, L309
cfi.c: L321, L387, L453, L616, L1453, L2309, L2385, L2402
nir/core.c: L204, L374, L437
nor/ecos.c: L134, L175
faux.c: L70, L58: pointer info is checked twice instead of info->memory
lpc2000.c: L73, L86, L157, L211, L436, L663
lpc288x.c: L141, L179
lpc2900.c: L1017, L1693
non_cfi.c: L477
ocl.c: L62, L153
pic32_mx.c: L76, L611
stellaris.c: L612
stm32x.c: L48, L761
... to be continuedgiven up

Lint also reports "out of bound" pointer access.
I think i have found some uninitalised pointers,
but have to go deeper in that before reporting
this. 

Before i do anything, i want to know if the
OpenOcd Developers are interested in improving
the code for better maintainance. Make it (from my sight)
more maintainable and secure. The problem is, that it is pretty hard
to extract the real errors from the 1 of messages lint
produce. It's like fixing only some special compiler errors and
leave the rest alone. 

Clearing means e. g.:
- Clear the tripple include of stdio in ercosboard.c
- Change if (... && ((cmd == SLB) | (cmd == CLB)) to
if( && ((cmd == SLB) || (cmd == CLB))
- Use unsigned variables for unsigned data like
  size, count, length, positive offsets...
- Use xU for unsigned constants.
- Check implicit cast (uint32_t -> uint16_t)
- Increase unambiguousness: n = last - first +1 or
  imaginär example a*b+c-d*25<<3.


Let me know, what you think.


Best Regards,




Carsten___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Øyvind Harboe]

On Wed, Dec 16, 2009 at 2:30 PM, Carsten Breuer
 wrote:
> Hi all,
>
>
> i have done a first quick test with lint over the
> OpenOcd-Sources (based on commit 74ce435d97ca4f6f81645d755d04123f075aa42b)
> from today.
>
> Lint report a truckload of problems.
>
> The first thing i had to learn was, that it is verry uncommon
> in OpenOCD to check the result of malloc.

This is a known problem where we gladly accept patches
to fix each case.

> Here is a quick list of only a handfull of files
> that don't check the result of malloc against NULL.
> (L stands for line):
>
> mflash.c: L 352
> nand/core.c: L501, L616, 653
> fileio.c: L83, L98
> lpc3180.c: L53, L518, L519, L652, L653, L657, L658
> aduc702x.c: L57, L77
> at91sam7c: L536, L539, L555, L642, L738, L789, L792, L808, L876
> arvf.c: L193, L309
> cfi.c: L321, L387, L453, L616, L1453, L2309, L2385, L2402
> nir/core.c: L204, L374, L437
> nor/ecos.c: L134, L175
> faux.c: L70, L58: pointer info is checked twice instead of info->memory
> lpc2000.c: L73, L86, L157, L211, L436, L663
> lpc288x.c: L141, L179
> lpc2900.c: L1017, L1693
> non_cfi.c: L477
> ocl.c: L62, L153
> pic32_mx.c: L76, L611
> stellaris.c: L612
> stm32x.c: L48, L761
> ... to be continuedgiven up
>
> Lint also reports "out of bound" pointer access.
> I think i have found some uninitalised pointers,
> but have to go deeper in that before reporting
> this.
>
> Before i do anything, i want to know if the
> OpenOcd Developers are interested in improving
> the code for better maintainance. Make it (from my sight)
> more maintainable and secure. The problem is, that it is pretty hard
> to extract the real errors from the 1 of messages lint
> produce. It's like fixing only some special compiler errors and
> leave the rest alone.

You will see by digging into the mailing list that we, the maintainers,
are always very interested in cleaning up the code and that we
gladly accept patches.

If you have a patch that would allow others to run lint using
an open source tool, then that would be well received.

> Clearing means e. g.:
> - Clear the tripple include of stdio in ercosboard.c

I do cleanup of this file in batches. This file is my responsiblity.
I'll fix this one for sure.

> - Change if (... && ((cmd == SLB) | (cmd == CLB)) to
>            if( && ((cmd == SLB) || (cmd == CLB))
> - Use unsigned variables for unsigned data like
>  size, count, length, positive offsets...
> - Use xU for unsigned constants.
> - Check implicit cast (uint32_t -> uint16_t)
> - Increase unambiguousness: n = last - first +1 or
>  imaginär example a*b+c-d*25<<3.

There may be some of these cases that are a matter
of opinion or taste, but generally following lint warnings/notes
is a good idea.



-- 
Ø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-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problem when tryng to flash LPC2368

[Marcelo Utikawa da Fonseca]

Thank you!

I will try FlashMagic later because I do not have Windows on my PC.
About the data in first 64 bytes I do not understand about them but
they are in the flash!
Please see the below logs showing this strange behaviour. I am using
the telnet to send commands:

1) Memory containing correct data:

> mdw 0 0x20
0x: e59ff018 e59ff018 e59ff018 e59ff018 e59ff018 b9206e58
e51ff120 e59ff010 
0x0020: 0038 1244 1258 121c 1230 126c
e59f0198 e321f0db 
0x0040: e1a0d000 e244 e321f0d7 e1a0d000 e244 e321f0d1
e1a0d000 e244 
0x0060: e321f0d2 e1a0d000 e2400040 e321f0d3 e1a0d000 e2400040
e321f0df e1a0d000 

2) Now I do a erase and show the data again:

> flash erase_sector 0 0 0
erased sectors 0 through 0 on flash bank 0 in 0.171872s
> mdw 0 0x20  
0x:      
  
0x0020:      
  
0x0040:      
  
0x0060:      
  

3) The flash seems to be erased. Now I turn off the board, turn on
again and reconnect the OpenOCD. Here is the result:

> halt
target state: halted
target halted in Thumb state due to debug-request, current mode:
Supervisor
cpsr: 0xa0f3 pc: 0x7fffe154
> mdw 0 0x20
0x: e59f4018 e59f5010 e5946000 e0056006 e5846000 e51ff004
7fffe040 bfff 
0x0020: 3fff8000     
  
0x0040:      
  
0x0060:      
  

In the J-Flash software, the command to read back the entire chip shows
only 0xff but the J-Link Commander can read exactly the same data:

SEGGER J-Link Commander V3.96d ('?' for help)

Compiled Nov 21 2008 19:00:17

DLL version V3.96d, compiled Nov 21 2008 18:59:52

Firmware: J-Link ARM V6 compiled Jun 30 2009 11:06:04

Hardware: V6.00

S/N : 156002960

OEM : IAR

VTarget = 3.319V

Info: TotalIRLen = 4, IRPrint = 0x01

Found 1 JTAG device, Total IRLen = 4:

 Id of device #0: 0x4F1F0F0F

Found ARM with core Id 0x4F1F0F0F (ARM7)

  ETM V1.2: 1 pairs addr.comp, 0 data comp, 4 MM decs, 1 counters

RTCK reaction time is approx. 189ns

Using adaptive clocking instead of fixed JTAG speed.

J-Link>mem 0 0x80

 = 18 40 9F E5 10 50 9F E5 00 60 94 E5 06 60 05 E0

0010 = 00 60 84 E5 04 F0 1F E5 40 E0 FF 7F FF BF FF FF

0020 = 00 80 FF 3F 00 00 00 00 00 00 00 00 00 00 00 00

0030 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0040 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

0050 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

0060 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

0070 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

J-Link>

What can be wrong?

Best regards,
Marcelo Utikawa da Fonseca

Nico Coesel escreveu:

  The first 64 bytes must always be erased. Try to use flashmagic instead of OpenOCD. 

These controllers use flash with ECC therefore you cannot program the flash partially / patch single bytes.

Nico Coesel


  
  
-Original Message-
From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
development-boun...@lists.berlios.de] On Behalf Of Marcelo Utikawa da
Fonseca
Sent: woensdag 16 december 2009 13:54
To: openocd-development@lists.berlios.de
Subject: Re: [Openocd-development] Problem when tryng to flash LPC2368

Hi again!

I am still having problems to write the flahs in  an LPC2368.

Now I know that the first 64 bytes is never erased. There is always data
in this area. 95% of the write errors are caused because the data is not
correctly programmed in this area.
In the J-Flash software, this area have data after a erase so I think
that the data in this area is correct.
I am using J-Link in both OpenOCD and J-Flash. I have tried a programmer
derivated from axm0432 and I receive the same results...

Could this be a bug in OpenOCD? It cannot write in this situation but
J-Flash can so the problem is not in the hardware or the programmer
because they are the same.

Best regards,
Marcelo Utikawa da Fonseca

Marcelo Utikawa da Fonseca escreveu:


  Hi!

First of all, I am new to this list.
My name is Marcelo Fonseca. I work in a Brazilian design house and have
experience with LPC21xx and LPC23xx from NXP and i.MX family from
  

Freescale.


  
I am having problems to write an LPC2368 with our custom board.
I can write it with a J-Link and J-Flash software from Segger.
In OpenOCD all seems to work but many times there are errors when trying
to write the flash memory using the GDB.
If I run a erase in the J-Flash software I have no error and OpenOCD
succesfully write to the flash memory.
When I run the "flash erase_sector" command in OpenOCD, J-Flash sa

Re: [Openocd-development] Problem when tryng to flash LPC2368

[Nico Coesel]

Utikawa,
There is also a Linux tool called lpc21isp to program lpc2000 devices
(http://sourceforge.net/projects/lpc21isp/).

Nico Coesel


From: openocd-development-boun...@lists.berlios.de
[mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of
Marcelo Utikawa da Fonseca
Sent: woensdag 16 december 2009 14:47
To: openocd-development@lists.berlios.de
Subject: Re: [Openocd-development] Problem when tryng to flash LPC2368

Thank you!

I will try FlashMagic later because I do not have Windows on my PC.
About the data in first 64 bytes I do not understand about them but they
are in the flash!
Please see the below logs showing this strange behaviour. I am using the
telnet to send commands:
FAX: 55-11-29412289
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problem when tryng to flash LPC2368

[Igor Skochinsky]

Hello Marcelo,

What you see is bootrom code that gets automatically mapped to 0 if
there is no user code or it's invalid.

"The interrupt vectors residing in the boot block of the on-chip flash
memory also become active after reset, i.e., the bottom 64 bytes of
the boot block are also visible in the memory region starting from the
address 0x . The reset vector contains a jump instruction to
the entry point of the flash boot loader software."

 LDR R4, =0x3FFF8000
0004 LDR R5, =0xBFFF
0008 LDR R6, [R4]
000C AND R6, R5, R6
0010 STR R6, [R4]
0014 LDR PC, =0x7FFFE040

0x7FFFE040 is the bootrom entrypoint.

"3.1.1 Criterion for Valid User Code
Criterion for valid user code: The reserved ARM interrupt vector
location (0x 0014) should contain the 2’s complement of the
check-sum of the remaining interrupt vectors. This causes the checksum
of all of the vectors together to be 0. The boot loader code disables
the overlaying of the interrupt vectors from the boot block, then
checksums the interrupt vectors in sector 0 of the flash. If the
signatures match then the execution control is transferred to the user
code by loading the program counter with 0x . Hence the user
flash reset vector should contain a jump instruction to the entry
point of the user application code."

My guess is that FlashMagic automatically patches the checksum to be correct.

On Wed, Dec 16, 2009 at 14:47, Marcelo Utikawa da Fonseca
 wrote:
> Thank you!
>
> I will try FlashMagic later because I do not have Windows on my PC.
> About the data in first 64 bytes I do not understand about them but they are
> in the flash!
> Please see the below logs showing this strange behaviour. I am using the
> telnet to send commands:
>
> 1) Memory containing correct data:
>
>> mdw 0 0x20
> 0x: e59ff018 e59ff018 e59ff018 e59ff018 e59ff018 b9206e58 e51ff120
> e59ff010
> 0x0020: 0038 1244 1258 121c 1230 126c e59f0198
> e321f0db
> 0x0040: e1a0d000 e244 e321f0d7 e1a0d000 e244 e321f0d1 e1a0d000
> e244
> 0x0060: e321f0d2 e1a0d000 e2400040 e321f0d3 e1a0d000 e2400040 e321f0df
> e1a0d000
>
> 2) Now I do a erase and show the data again:
>
>> flash erase_sector 0 0 0
> erased sectors 0 through 0 on flash bank 0 in 0.171872s
>> mdw 0 0x20
> 0x:       
> 
> 0x0020:       
> 
> 0x0040:       
> 
> 0x0060:       
> 
>
> 3) The flash seems to be erased. Now I turn off the board, turn on again and
> reconnect the OpenOCD. Here is the result:
>
>> halt
> target state: halted
> target halted in Thumb state due to debug-request, current mode: Supervisor
> cpsr: 0xa0f3 pc: 0x7fffe154
>> mdw 0 0x20
> 0x: e59f4018 e59f5010 e5946000 e0056006 e5846000 e51ff004 7fffe040
> bfff
> 0x0020: 3fff8000      
> 
> 0x0040:       
> 
> 0x0060:       
> 
>
> In the J-Flash software, the command to read back the entire chip shows only
> 0xff but the J-Link Commander can read exactly the same data:
>
> SEGGER J-Link Commander V3.96d ('?' for help)
> Compiled Nov 21 2008 19:00:17
> DLL version V3.96d, compiled Nov 21 2008 18:59:52
> Firmware: J-Link ARM V6 compiled Jun 30 2009 11:06:04
> Hardware: V6.00
> S/N : 156002960
> OEM : IAR
> VTarget = 3.319V
> Info: TotalIRLen = 4, IRPrint = 0x01
> Found 1 JTAG device, Total IRLen = 4:
>  Id of device #0: 0x4F1F0F0F
> Found ARM with core Id 0x4F1F0F0F (ARM7)
>   ETM V1.2: 1 pairs addr.comp, 0 data comp, 4 MM decs, 1 counters
> RTCK reaction time is approx. 189ns
> Using adaptive clocking instead of fixed JTAG speed.
> J-Link>mem 0 0x80
>  = 18 40 9F E5 10 50 9F E5 00 60 94 E5 06 60 05 E0
> 0010 = 00 60 84 E5 04 F0 1F E5 40 E0 FF 7F FF BF FF FF
> 0020 = 00 80 FF 3F 00 00 00 00 00 00 00 00 00 00 00 00
> 0030 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0040 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> 0050 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> 0060 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> 0070 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> J-Link>
>
> What can be wrong?
>
> Best regards,
> Marcelo Utikawa da Fonseca
>
> Nico Coesel escreveu:
>
> The first 64 bytes must always be erased. Try to use flashmagic instead of
> OpenOCD.
>
> These controllers use flash with ECC therefore you cannot program the flash
> partially / patch single bytes.
>
> Nico Coesel
>
>
>
>
> -Origina

Re: [Openocd-development] Problem when tryng to flash LPC2368

[Nico Coesel]

> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Igor Skochinsky
> Sent: woensdag 16 december 2009 16:01
> To: Marcelo Utikawa da Fonseca
> Cc: openocd-development@lists.berlios.de
> Subject: Re: [Openocd-development] Problem when tryng to flash LPC2368
> 
> Hello Marcelo,
> 
> What you see is bootrom code that gets automatically mapped to 0 if
> there is no user code or it's invalid.
> 
> "The interrupt vectors residing in the boot block of the on-chip flash
> memory also become active after reset, i.e., the bottom 64 bytes of
> the boot block are also visible in the memory region starting from the
> address 0x . The reset vector contains a jump instruction to
> the entry point of the flash boot loader software."
> 
>  LDR R4, =0x3FFF8000
> 0004 LDR R5, =0xBFFF
> 0008 LDR R6, [R4]
> 000C AND R6, R5, R6
> 0010 STR R6, [R4]
> 0014 LDR PC, =0x7FFFE040
> 
> 0x7FFFE040 is the bootrom entrypoint.
> 
> "3.1.1 Criterion for Valid User Code
> Criterion for valid user code: The reserved ARM interrupt vector
> location (0x 0014) should contain the 2's complement of the
> check-sum of the remaining interrupt vectors. This causes the checksum
> of all of the vectors together to be 0. The boot loader code disables
> the overlaying of the interrupt vectors from the boot block, then
> checksums the interrupt vectors in sector 0 of the flash. If the
> signatures match then the execution control is transferred to the user
> code by loading the program counter with 0x . Hence the user
> flash reset vector should contain a jump instruction to the entry
> point of the user application code."
> 
> My guess is that FlashMagic automatically patches the checksum to be
> correct.

IIRC OpenOCD should do this or has this function been deleted? I recall
some discussion about that but I don't remember the outcome. I can't
imagine OpenOCD doesn't calculate the checksum. All compiler / linker
tools more or less assume the programming software takes care of
creating the checksum.
 
Nico Coesel

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problem when tryng to flash LPC2368

[Øyvind Harboe]

> IIRC OpenOCD should do this or has this function been deleted? I recall
> some discussion about that but I don't remember the outcome. I can't
> imagine OpenOCD doesn't calculate the checksum. All compiler / linker
> tools more or less assume the programming software takes care of
> creating the checksum.

There are a few things that I vaguely recall here:

- the reset init sequence needs to disable some lpc memory mapping
for the flash driver to work
- the flash driver has the option to calculate the checksum (which can
cause verification to report a false positive on failure in some cases)

-- 
Ø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-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problem when tryng to flash LPC2368

[Igor Skochinsky]

Marcelo,

The current lpc2000.c mentions this:

/*
* flash bank lpc2000   0 0   
[calc_checksum]
*/

Have you tried adding "calc_checksum"?

On Wed, Dec 16, 2009 at 16:13, Nico Coesel  wrote:
>> -Original Message-
>> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
>> development-boun...@lists.berlios.de] On Behalf Of Igor Skochinsky
>> Sent: woensdag 16 december 2009 16:01
>> To: Marcelo Utikawa da Fonseca
>> Cc: openocd-development@lists.berlios.de
>> Subject: Re: [Openocd-development] Problem when tryng to flash LPC2368
>>
>> Hello Marcelo,
>>
>> What you see is bootrom code that gets automatically mapped to 0 if
>> there is no user code or it's invalid.
>>
>> "The interrupt vectors residing in the boot block of the on-chip flash
>> memory also become active after reset, i.e., the bottom 64 bytes of
>> the boot block are also visible in the memory region starting from the
>> address 0x . The reset vector contains a jump instruction to
>> the entry point of the flash boot loader software."
>>
>>                  LDR     R4, =0x3FFF8000
>> 0004                 LDR     R5, =0xBFFF
>> 0008                 LDR     R6, [R4]
>> 000C                 AND     R6, R5, R6
>> 0010                 STR     R6, [R4]
>> 0014                 LDR     PC, =0x7FFFE040
>>
>> 0x7FFFE040 is the bootrom entrypoint.
>>
>> "3.1.1 Criterion for Valid User Code
>> Criterion for valid user code: The reserved ARM interrupt vector
>> location (0x 0014) should contain the 2's complement of the
>> check-sum of the remaining interrupt vectors. This causes the checksum
>> of all of the vectors together to be 0. The boot loader code disables
>> the overlaying of the interrupt vectors from the boot block, then
>> checksums the interrupt vectors in sector 0 of the flash. If the
>> signatures match then the execution control is transferred to the user
>> code by loading the program counter with 0x . Hence the user
>> flash reset vector should contain a jump instruction to the entry
>> point of the user application code."
>>
>> My guess is that FlashMagic automatically patches the checksum to be
>> correct.
>
> IIRC OpenOCD should do this or has this function been deleted? I recall
> some discussion about that but I don't remember the outcome. I can't
> imagine OpenOCD doesn't calculate the checksum. All compiler / linker
> tools more or less assume the programming software takes care of
> creating the checksum.
>
> Nico Coesel
>
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>



-- 
WBR, Igor
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problem when tryng to flash LPC2368

[Marcelo Utikawa da Fonseca]

First of all, thanks for everyone helping me to solve this issue! :-)

Igor:
I am sorry! Now I found the text about memory map after a reset. The
problem regarding the first 64 bytes was solved.
Now I just need to know how to disable this memory map...
About calc_checksum, I am already using it:

flash bank lpc2000 0x0 0x8 0 0 0 lpc2000_v2 12000 calc_checksum

Nico:
lpc21isp will be a very useful tool! I will try it. thank you very much!

I still need OpenOCD to debug software using GDB.
When the gdb succesfully write to the flash memory, the program starts
and reaches a breakpoint in main. When it fails, the breakpoint is
never reached. When I stop gdb, pc is in 0xc address (undefined
instruction vector).
After gdb write to memory, I run the command:

monitor mdw 0 0x20

sometimes it shows the same initial 64 bytes (now I know that this is
the mapped memory) and sometimes the correct data.
Why sometimes it works and sometimes it do not?
How can I disable this memory to be mapped?
I will search for this, any news I will send to the list!

Thank you very much again!

Best regards,
Marcelo Utikawa da Fonseca

Igor Skochinsky escreveu:

  Marcelo,

The current lpc2000.c mentions this:

/*
* flash bank lpc2000   0 0   
[calc_checksum]
*/

Have you tried adding "calc_checksum"?

On Wed, Dec 16, 2009 at 16:13, Nico Coesel  wrote:
  
  

  -Original Message-
From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
development-boun...@lists.berlios.de] On Behalf Of Igor Skochinsky
Sent: woensdag 16 december 2009 16:01
To: Marcelo Utikawa da Fonseca
Cc: openocd-development@lists.berlios.de
Subject: Re: [Openocd-development] Problem when tryng to flash LPC2368

Hello Marcelo,

What you see is bootrom code that gets automatically mapped to 0 if
there is no user code or it's invalid.

"The interrupt vectors residing in the boot block of the on-chip flash
memory also become active after reset, i.e., the bottom 64 bytes of
the boot block are also visible in the memory region starting from the
address 0x . The reset vector contains a jump instruction to
the entry point of the flash boot loader software."

                 LDR     R4, =0x3FFF8000
0004                 LDR     R5, =0xBFFF
0008                 LDR     R6, [R4]
000C                 AND     R6, R5, R6
0010                 STR     R6, [R4]
0014                 LDR     PC, =0x7FFFE040

0x7FFFE040 is the bootrom entrypoint.

"3.1.1 Criterion for Valid User Code
Criterion for valid user code: The reserved ARM interrupt vector
location (0x 0014) should contain the 2's complement of the
check-sum of the remaining interrupt vectors. This causes the checksum
of all of the vectors together to be 0. The boot loader code disables
the overlaying of the interrupt vectors from the boot block, then
checksums the interrupt vectors in sector 0 of the flash. If the
signatures match then the execution control is transferred to the user
code by loading the program counter with 0x . Hence the user
flash reset vector should contain a jump instruction to the entry
point of the user application code."

My guess is that FlashMagic automatically patches the checksum to be
correct.
  

IIRC OpenOCD should do this or has this function been deleted? I recall
some discussion about that but I don't remember the outcome. I can't
imagine OpenOCD doesn't calculate the checksum. All compiler / linker
tools more or less assume the programming software takes care of
creating the checksum.

Nico Coesel

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


  
  


  





-Tecnequip Tecnologia em EquipamentosEndereço/Address: R. Ganges, 557Cidade/City: São PauloEstado/State: SPPaís/Country: BrasilCEP/Postal Code: 03445-030Fone/Phone: 55-11-20937199FAX: 55-11-29412289
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problem when tryng to flash LPC2368

[Igor Skochinsky]

Marcelo,

  Try changing the MEMMAP register (see User Manual for details).

On Wed, Dec 16, 2009 at 17:05, Marcelo Utikawa da Fonseca
 wrote:
> First of all, thanks for everyone helping me to solve this issue! :-)
>
> Igor:
> I am sorry! Now I found the text about memory map after a reset. The problem
> regarding the first 64 bytes was solved.
> Now I just need to know how to disable this memory map...
> About calc_checksum, I am already using it:
>
> flash bank lpc2000 0x0 0x8 0 0 0 lpc2000_v2 12000 calc_checksum
>
> Nico:
> lpc21isp will be a very useful tool! I will try it. thank you very much!
>
> I still need OpenOCD to debug software using GDB.
> When the gdb succesfully write to the flash memory, the program starts and
> reaches a breakpoint in main. When it fails, the breakpoint is never
> reached. When I stop gdb, pc is in 0xc address (undefined instruction
> vector).
> After gdb write to memory, I run the command:
>
> monitor mdw 0 0x20
>
> sometimes it shows the same initial 64 bytes (now I know that this is the
> mapped memory) and sometimes the correct data.
> Why sometimes it works and sometimes it do not?
> How can I disable this memory to be mapped?
> I will search for this, any news I will send to the list!
>
> Thank you very much again!
>
> Best regards,
> Marcelo Utikawa da Fonseca
>
> Igor Skochinsky escreveu:
>
> Marcelo,
>
> The current lpc2000.c mentions this:
>
> /*
> * flash bank lpc2000   0 0   
> [calc_checksum]
> */
>
> Have you tried adding "calc_checksum"?
>
> On Wed, Dec 16, 2009 at 16:13, Nico Coesel  wrote:
>
>
> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Igor Skochinsky
> Sent: woensdag 16 december 2009 16:01
> To: Marcelo Utikawa da Fonseca
> Cc: openocd-development@lists.berlios.de
> Subject: Re: [Openocd-development] Problem when tryng to flash LPC2368
>
> Hello Marcelo,
>
> What you see is bootrom code that gets automatically mapped to 0 if
> there is no user code or it's invalid.
>
> "The interrupt vectors residing in the boot block of the on-chip flash
> memory also become active after reset, i.e., the bottom 64 bytes of
> the boot block are also visible in the memory region starting from the
> address 0x . The reset vector contains a jump instruction to
> the entry point of the flash boot loader software."
>
>                  LDR     R4, =0x3FFF8000
> 0004                 LDR     R5, =0xBFFF
> 0008                 LDR     R6, [R4]
> 000C                 AND     R6, R5, R6
> 0010                 STR     R6, [R4]
> 0014                 LDR     PC, =0x7FFFE040
>
> 0x7FFFE040 is the bootrom entrypoint.
>
> "3.1.1 Criterion for Valid User Code
> Criterion for valid user code: The reserved ARM interrupt vector
> location (0x 0014) should contain the 2's complement of the
> check-sum of the remaining interrupt vectors. This causes the checksum
> of all of the vectors together to be 0. The boot loader code disables
> the overlaying of the interrupt vectors from the boot block, then
> checksums the interrupt vectors in sector 0 of the flash. If the
> signatures match then the execution control is transferred to the user
> code by loading the program counter with 0x . Hence the user
> flash reset vector should contain a jump instruction to the entry
> point of the user application code."
>
> My guess is that FlashMagic automatically patches the checksum to be
> correct.
>
>
> IIRC OpenOCD should do this or has this function been deleted? I recall
> some discussion about that but I don't remember the outcome. I can't
> imagine OpenOCD doesn't calculate the checksum. All compiler / linker
> tools more or less assume the programming software takes care of
> creating the checksum.
>
> Nico Coesel
>
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
>
>
>
>
> -
> Tecnequip Tecnologia em Equipamentos
> Endereço/Address: R. Ganges, 557
> Cidade/City: São Paulo
> Estado/State: SP
> País/Country: Brasil
> CEP/Postal Code: 03445-030
> Fone/Phone: 55-11-20937199
> FAX: 55-11-29412289
>
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
>



-- 
WBR, Igor
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problem when tryng to flash LPC2368

[Marcelo Utikawa da Fonseca]

Great, now it is working! :-)

I put the following line in my gdb config file:

monitor mwb 0xe01fc040 0x01

Thank you!

Best regards,
Marcelo Utikawa da Fonseca

Igor Skochinsky escreveu:

  Marcelo,

  Try changing the MEMMAP register (see User Manual for details).

On Wed, Dec 16, 2009 at 17:05, Marcelo Utikawa da Fonseca
 wrote:
  
  
First of all, thanks for everyone helping me to solve this issue! :-)

Igor:
I am sorry! Now I found the text about memory map after a reset. The problem
regarding the first 64 bytes was solved.
Now I just need to know how to disable this memory map...
About calc_checksum, I am already using it:

flash bank lpc2000 0x0 0x8 0 0 0 lpc2000_v2 12000 calc_checksum

Nico:
lpc21isp will be a very useful tool! I will try it. thank you very much!

I still need OpenOCD to debug software using GDB.
When the gdb succesfully write to the flash memory, the program starts and
reaches a breakpoint in main. When it fails, the breakpoint is never
reached. When I stop gdb, pc is in 0xc address (undefined instruction
vector).
After gdb write to memory, I run the command:

monitor mdw 0 0x20

sometimes it shows the same initial 64 bytes (now I know that this is the
mapped memory) and sometimes the correct data.
Why sometimes it works and sometimes it do not?
How can I disable this memory to be mapped?
I will search for this, any news I will send to the list!

Thank you very much again!

Best regards,
Marcelo Utikawa da Fonseca

Igor Skochinsky escreveu:

Marcelo,

The current lpc2000.c mentions this:

/*
* flash bank lpc2000   0 0   
[calc_checksum]
*/

Have you tried adding "calc_checksum"?

On Wed, Dec 16, 2009 at 16:13, Nico Coesel  wrote:


-Original Message-
From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
development-boun...@lists.berlios.de] On Behalf Of Igor Skochinsky
Sent: woensdag 16 december 2009 16:01
To: Marcelo Utikawa da Fonseca
Cc: openocd-development@lists.berlios.de
Subject: Re: [Openocd-development] Problem when tryng to flash LPC2368

Hello Marcelo,

What you see is bootrom code that gets automatically mapped to 0 if
there is no user code or it's invalid.

"The interrupt vectors residing in the boot block of the on-chip flash
memory also become active after reset, i.e., the bottom 64 bytes of
the boot block are also visible in the memory region starting from the
address 0x . The reset vector contains a jump instruction to
the entry point of the flash boot loader software."

                 LDR     R4, =0x3FFF8000
0004                 LDR     R5, =0xBFFF
0008                 LDR     R6, [R4]
000C                 AND     R6, R5, R6
0010                 STR     R6, [R4]
0014                 LDR     PC, =0x7FFFE040

0x7FFFE040 is the bootrom entrypoint.

"3.1.1 Criterion for Valid User Code
Criterion for valid user code: The reserved ARM interrupt vector
location (0x 0014) should contain the 2's complement of the
check-sum of the remaining interrupt vectors. This causes the checksum
of all of the vectors together to be 0. The boot loader code disables
the overlaying of the interrupt vectors from the boot block, then
checksums the interrupt vectors in sector 0 of the flash. If the
signatures match then the execution control is transferred to the user
code by loading the program counter with 0x . Hence the user
flash reset vector should contain a jump instruction to the entry
point of the user application code."

My guess is that FlashMagic automatically patches the checksum to be
correct.


IIRC OpenOCD should do this or has this function been deleted? I recall
some discussion about that but I don't remember the outcome. I can't
imagine OpenOCD doesn't calculate the checksum. All compiler / linker
tools more or less assume the programming software takes care of
creating the checksum.

Nico Coesel

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development





-
Tecnequip Tecnologia em Equipamentos
Endereço/Address: R. Ganges, 557
Cidade/City: São Paulo
Estado/State: SP
País/Country: Brasil
CEP/Postal Code: 03445-030
Fone/Phone: 55-11-20937199
FAX: 55-11-29412289

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development



  
  


  





-Tecnequip Tecnologia em EquipamentosEndereço/Address: R. Ganges, 557Cidade/City: São PauloEstado/State: SPPaís/Country: BrasilCEP/Postal Code: 03445-030Fone/Phone: 55-11-20937199FAX: 55-11-29412289
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problem when tryng to flash LPC2368

[Øyvind Harboe]

On Wed, Dec 16, 2009 at 5:52 PM, Marcelo Utikawa da Fonseca
 wrote:
> Great, now it is working! :-)
>
> I put the following line in my gdb config file:
>
> monitor mwb 0xe01fc040 0x01
>
> Thank you!

That's great, but actually that mwb should probably go into the
reset init sequence inside the config file I think.

Now please post to the complete solution to the list.

You probably want to see that config file go into the the next
release of OpenOCD, right?

Also what version of OpenOCD are you running? It says 0.2.0 and
that's an old version.

Can I ask where you got it and why you
decided to try with an older version?



-- 
Ø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-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Problem when tryng to flash LPC2368

[David Brownell]

On Wednesday 16 December 2009, Marcelo Utikawa da Fonseca wrote:
> 
> 
> 
>  
> 
> 

Please fix your mailer so that it doesn't post HTML to this list.

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD Coding (was broken)

[Carsten Breuer]

Hi Øyvind,

> Of course resources tracking in C++ and exception handling comes to
> mind as a much more robust solution to such problems. I'm not
> arguing for using C++, I'm just saying that 

That's exactly what i thought when i see all the
malloc's in OpenOcd. I think, that there are still
a lot of memory leaks there. Are there any plans too switch
over to C++? There could be some great base classes
with virtual functions for the drivers and all this
allocation stuff could be handled in classes.


Best Regards,



Carsten
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD Coding (was broken)

[Dean Glazeski]

>
> That's exactly what i thought when i see all the
> malloc's in OpenOcd. I think, that there are still
> a lot of memory leaks there. Are there any plans too switch
> over to C++? There could be some great base classes
> with virtual functions for the drivers and all this
> allocation stuff could be handled in classes.


Nooo!  Don't start this again! :)

I was actually just talking with a friend about C++ and virtual tables.  We
might actually see a significant performance hit with virtual functions.  My
case in point is the NAND driver.  If the driver doesn't have a better read
page function, we just sit there and call a read function on a controller
over and over again until we read enough.  This could be bad if we also have
to look up the virtual table to get the right function.  This might cause
issues for ZY1000, if I understand how that system works :).

// Dean Glazeski
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Carsten Breuer]

Hi Øyvind,


>> The first thing i had to learn was, that it is verry uncommon in
>> OpenOCD to check the result of malloc.
> This is a known problem where we gladly accept patches to fix each
> case.

OK, then i will start to fix all the mallocs
that are handled not correct yet and where
i understand what to do if they fail.

> You will see by digging into the mailing list that we, the
> maintainers, are always very interested in cleaning up the code and
> that we gladly accept patches.

Fine, that's good to hear.
I don't want to spend a lot of hours directly for /dev/null ;-).

> If you have a patch that would allow others to run lint using an open
> source tool, then that would be well received.

It would be good to have a make target for that,
so that users who have lint of there computers
can run it. Something like "./configure --with-lint"

But this comes later.

> I do cleanup of this file in batches. This file is my responsiblity.
> I'll fix this one for sure.

OK, the i leave this out.

> There may be some of these cases that are a matter of opinion or
> taste, but generally following lint warnings/notes is a good idea.

Ok. I know that some stuff can "taste not so good".
So I only change things that i classify as important.

Best Regards,



Carsten
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD Coding (was broken)

[Øyvind Harboe]

On Wed, Dec 16, 2009 at 8:43 PM, Carsten Breuer
 wrote:
> Hi Øyvind,
>
>> Of course resources tracking in C++ and exception handling comes to
>> mind as a much more robust solution to such problems. I'm not
>> arguing for using C++, I'm just saying that 
>
> That's exactly what i thought when i see all the
> malloc's in OpenOcd. I think, that there are still
> a lot of memory leaks there. Are there any plans too switch
> over to C++?

None. There is no interest amongst the maintainers.

We know of no *significant* memory leaks today
and we accept patches to fix all malloc() / resource tracking
problems.

Do you know of any real memory leak(other than missing
checks on small malloc()'s)?

-- 
Ø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-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Øyvind Harboe]

On Wed, Dec 16, 2009 at 9:00 PM, Carsten Breuer
 wrote:
> Hi Øyvind,
>
>
>>> The first thing i had to learn was, that it is verry uncommon in
>>> OpenOCD to check the result of malloc.
>> This is a known problem where we gladly accept patches to fix each
>> case.
>
> OK, then i will start to fix all the mallocs
> that are handled not correct yet and where
> i understand what to do if they fail.

Great! I think if you do a pass on the *simple* cases and
just mark w/todo on the remaining ones that would be *great*.

I think it makes sense to split this into many commits. Minimally
one per file. I take it you are familiar with how to create a patch
series?

>> You will see by digging into the mailing list that we, the
>> maintainers, are always very interested in cleaning up the code and
>> that we gladly accept patches.
>
> Fine, that's good to hear.
> I don't want to spend a lot of hours directly for /dev/null ;-).

Focus on a handful of malloc()'s just ot get the procedure right
w.r.t. committing to git, submitting patches, etc.


>> There may be some of these cases that are a matter of opinion or
>> taste, but generally following lint warnings/notes is a good idea.
>
> Ok. I know that some stuff can "taste not so good".
> So I only change things that i classify as important.

Start with the obviously broken and move down the list...


-- 
Ø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-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD Coding (was broken)

[Carsten Breuer]

Hi Dean,

>> ...any plans too switch over to C++? There could be some great base
> Nooo!  Don't start this again! :)

Ups. Sorry. It looks like that i have the talent to ask the
wrong questions in the wrong group ;-).
 
> I was actually just talking with a friend about C++ and virtual
> tables.  We might actually see a significant performance hit with
> virtual functions. My case in point is the NAND driver.  If the
> driver doesn't have a better read page function, we just sit there
> and call a read function on a controller over and over again until we
> read enough.  This could be bad if we also have to look up the
> virtual table to get the right function.  This might cause issues for
> ZY1000, if I understand how that system works :).

The correct function is selected by the compiler and the overhead
is IMO in our area not an issue.

QT  and with it KDE are build on virtual functions. The hole frameworks
rely on it. If we have to deal with GBit/s this would be an issue.
But in our "environment" this is IMO not an issue.

Best Regards,



Carsten
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD Coding (was broken)

[Carsten Breuer]

Hi Øyvind, hi all.

>> Are there any plans too switch over to C++?
> None. There is no interest amongst the maintainers.
> We know of no *significant* memory leaks today and we accept patches
> to fix all malloc() / resource tracking problems.
> Do you know of any real memory leak(other than missing checks on
> small malloc()'s)?

No, i don't.
I didn't check anything in that direction.

Best regards,



Carsten

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Carsten Breuer]

Hi Øyvind,


>> OK, then i will start to fix all the mallocs that are handled not
>> correct yet and where i understand what to do if they fail.
> Great! I think if you do a pass on the *simple* cases and just mark
> w/todo on the remaining ones that would be *great*. I think it makes
> sense to split this into many commits. Minimally one per file. I take
> it you are familiar with how to create a patch series?

I know it in subversion, but not in git.
I would do the following:

for number_of_mallocs:
{
- fix the file
- see if it compiles.
- create a patch
- send it too you.
}

Is there any windows client that you can suggest?
Something like TortoiseGIT?

> Focus on a handful of malloc()'s just ot get the procedure right
> w.r.t. committing to git, submitting patches, etc.

Yes, smaller commits are better and easier to merge. agreed.

>> Start with the obviously broken and move down the list...

OK.

Best Regards,



Carsten

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD Coding (was broken)

[Albert ARIBAUD]

Carsten Breuer a écrit :

> The correct function is selected by the compiler and the overhead
> is IMO in our area not an issue.

In embedded developpment, "IMO" can be argued to be not precise enough.

> QT  and with it KDE are build on virtual functions. 

But then, QT and KDE do not have a requirement to "communicate with CPUs 
for embedded debugging purposes, including watching them running, on a 
not-so-fast serial link".

Amicalement,
-- 
Albert.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Thomas Kindler]

Carsten Breuer wrote:
>>> The first thing i had to learn was, that it is verry uncommon in
>>> OpenOCD to check the result of malloc.
 >>>
>> This is a known problem where we gladly accept patches to fix each
>> case.
> 
> OK, then i will start to fix all the mallocs
> that are handled not correct yet and where
> i understand what to do if they fail.

On a normal, modern operating system, (reasonably sized) mallocs should
never fail, as the system will start thrashing and killing off processes
long before malloc() fails.

(This will be a different story for the Zy1000, of course..)

best regards,
-- 
Thomas Kindler 
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Thomas Kindler]

Carsten Breuer wrote:
> Is there any windows client that you can suggest?
> Something like TortoiseGIT?

Sure. TortoiseGit.

;)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD Coding (was broken)

[Øyvind Harboe]

On Wed, Dec 16, 2009 at 9:13 PM, Carsten Breuer
 wrote:
> Hi Dean,
>
>>> ...any plans too switch over to C++? There could be some great base
>> Nooo!  Don't start this again! :)
>
> Ups. Sorry. It looks like that i have the talent to ask the
> wrong questions in the wrong group ;-).

You're just keeping up a tradition. Every few weeks or
months there is a suggestion to change language or
depend on some fantastic new tool or methodology. :-)

The trick is not to get stuck in hopelessly old technologies
while not becoming victim of some passing fad.

The C language seems to be firmly entrenched with OpenOCD,
so I don't see any change there for a lng time.

-- 
Ø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-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Øyvind Harboe]

On Wed, Dec 16, 2009 at 9:36 PM, Thomas Kindler  wrote:
> Carsten Breuer wrote:
 The first thing i had to learn was, that it is verry uncommon in
 OpenOCD to check the result of malloc.
>  >>>
>>> This is a known problem where we gladly accept patches to fix each
>>> case.
>>
>> OK, then i will start to fix all the mallocs
>> that are handled not correct yet and where
>> i understand what to do if they fail.
>
> On a normal, modern operating system, (reasonably sized) mallocs should
> never fail, as the system will start thrashing and killing off processes
> long before malloc() fails.
>
> (This will be a different story for the Zy1000, of course..)

The zy1000 has "infinite" ram w.r.t. small allocations(32 or
64mBytes depending on revision), so not checking small
allocations is *highly unlikely * to cause problems for any
embedded host with oodles of ram(megabytes).

-- 
Ø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-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Øyvind Harboe]

On Wed, Dec 16, 2009 at 9:22 PM, Carsten Breuer
 wrote:
> Hi Øyvind,
>
>
>>> OK, then i will start to fix all the mallocs that are handled not
>>> correct yet and where i understand what to do if they fail.
>> Great! I think if you do a pass on the *simple* cases and just mark
>> w/todo on the remaining ones that would be *great*. I think it makes
>> sense to split this into many commits. Minimally one per file. I take
>> it you are familiar with how to create a patch series?
>
> I know it in subversion, but not in git.
> I would do the following:
>
> for number_of_mallocs:
> {
>    - fix the file
>    - see if it compiles.
>    - create a patch
>    - send it too you.
> }

No.

- fix a file(including build it)
- commit to local git

Once you're done you can create a patch series and email
it to the list.

You then get some comments, do an interactive rebase
and resubmit the patch list.

> Is there any windows client that you can suggest?
> Something like TortoiseGIT?
>
>> Focus on a handful of malloc()'s just ot get the procedure right
>> w.r.t. committing to git, submitting patches, etc.
>
> Yes, smaller commits are better and easier to merge. agreed.

+ easier for you to rebase.

For a problem like this you *really* need to read  up
on maintaining git. I recommend using command line
tools for something like this. TortoiseGit/gui's are almost
certainly the wrong way to go as they are hopelessly far
behind git and tend to try to treat git as svn, which defeats
much of the purpose of using git in the first place.

You will find that learning git(which is a prime example of the
DVCS - distributed version control) will be an excellent investment
of your time in the years to come.


-- 
Ø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-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Disabling svn server on berlios

[Øyvind Harboe]

The berlios openocd svn server is now disabled.

Use the git repository Luke! :-)

If someone *must* below is the last svn snapshot.

I don't want to plaster this link on the OpenOCD web pages for
fear of someone not going to git, but here it is for reference:

http://download.berlios.de/svndumps/openocd-repos.gz


-- 
Ø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-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Lennert Buytenhek]

On Wed, Dec 16, 2009 at 09:46:29PM +0100, Øyvind Harboe wrote:

> > for number_of_mallocs:
> > {
> >    - fix the file
> >    - see if it compiles.
> >    - create a patch
> >    - send it too you.
> > }
> 
> No.
> 
> - fix a file(including build it)
> - commit to local git

While I am of the opinion that git is the greatest thing since sliced
bread, I don't think that it is a good idea to require that people learn
some VCS they aren't familiar with to contribute to a project.

E.g. if someone is already familiar with quilt, they can do most of the
local patch management they need without having to learn git (even if
the latter is a good idea, it should not be required upfront).

In this case, if someone sends a patch series to the list, I don't
think it should matter which VCS was used to manage that patch series
during local development.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [patch/FYI 0/5] misc cleanup pages

[David Brownell]

The helptext for "flash fillw ..." and siblings was wrong;
those commands don't take a bank ID.  Fixed.

Plus:  shrink "scan_chain" output to fit on normal terminals;
and various cleanups for the Stellaris driver, which won't be
changing behavior significantly.
 
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [patch/FYI 1/5] JTAG: shrink "scan_chain" output

[David Brownell]

Tweak the "scan_chain" output by removing column separators.  Also
remove the "current instruction" state ... which changes constantly.

Now its style resembles the "targets" output, and can even fit on
one line in standard terminals and in the PDF docs.
---
 doc/openocd.texi |   14 +++---
 src/jtag/tcl.c   |   16 
 2 files changed, 15 insertions(+), 15 deletions(-)

--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -2592,13 +2592,15 @@ debugging targets.)
 Here's what the scan chain might look like for a chip more than one TAP:
 
 @verbatim
-   TapNameEnabled IdCode Expected   IrLen IrCap IrMask Instr
--- -- --- -- -- - - -- -
- 0 omap5912.dsp  Y0x03df1d81 0x03df1d81 380 0  0x...
- 1 omap5912.arm  Y0x0692602f 0x0692602f 4 0x1   0  0xc
- 2 omap5912.unknown  Y0x 0x 8 0 0  0xff
+   TapNameEnabled IdCode Expected   IrLen IrCap IrMask
+-- -- --- -- -- - - --
+ 0 omap5912.dsp  Y0x03df1d81 0x03df1d8138 0x01  0x03
+ 1 omap5912.arm  Y0x0692602f 0x0692602f 4 0x01  0x0f
+ 2 omap5912.unknown  Y0x 0x 8 0x01  0x03
 @end verbatim
 
+OpenOCD can detect some of that information, but not all
+of it.  @xref{Autoprobing}.
 Unfortunately those TAPs can't always be autoconfigured,
 because not all devices provide good support for that.
 JTAG doesn't require supporting IDCODE instructions, and
@@ -2659,8 +2661,6 @@ The set of TAPs listed by this command i
 exiting the OpenOCD configuration stage,
 but systems with a JTAG router can
 enable or disable TAPs dynamically.
-In addition to the enable/disable status, the contents of
-each TAP's instruction register can also change.
 @end deffn
 
 @c FIXME!  "jtag cget" should be able to return all TAP
--- a/src/jtag/tcl.c
+++ b/src/jtag/tcl.c
@@ -1021,11 +1021,13 @@ COMMAND_HANDLER(handle_scan_chain_comman
char expected_id[12];
 
tap = jtag_all_taps();
-   command_print(CMD_CTX, " TapName| Enabled |   IdCode
  ExpectedIrLen IrCap  IrMask Instr ");
-   command_print(CMD_CTX, 
"---||-|||--|--|--|-");
+   command_print(CMD_CTX,
+"   TapName Enabled  IdCode Expected   IrLen IrCap IrMask");
+   command_print(CMD_CTX,
+"-- ---  -- -- - - --");
 
while (tap) {
-   uint32_t expected, expected_mask, cur_instr, ii;
+   uint32_t expected, expected_mask, ii;
 
snprintf(expected_id, sizeof expected_id, "0x%08x",
(unsigned)((tap->expected_ids_cnt > 0)
@@ -1036,10 +1038,9 @@ COMMAND_HANDLER(handle_scan_chain_comman
 
expected = buf_get_u32(tap->expected, 0, tap->ir_length);
expected_mask = buf_get_u32(tap->expected_mask, 0, 
tap->ir_length);
-   cur_instr = buf_get_u32(tap->cur_instr, 0, tap->ir_length);
 
command_print(CMD_CTX,
-   "%2d | %-18s |%c| 0x%08x | %s | 0x%02x | 0x%02x | 0x%02x | 
0x%02x",
+   "%2d %-18s %c 0x%08x %s %5d 0x%02x  0x%02x",
  tap->abs_chain_position,
  tap->dotted_name,
  tap->enabled ? 'Y' : 'n',
@@ -1047,8 +1048,7 @@ COMMAND_HANDLER(handle_scan_chain_comman
  expected_id,
  (unsigned int)(tap->ir_length),
  (unsigned int)(expected),
- (unsigned int)(expected_mask),
- (unsigned int)(cur_instr));
+ (unsigned int)(expected_mask));
 
for (ii = 1; ii < tap->expected_ids_cnt; ii++) {
snprintf(expected_id, sizeof expected_id, "0x%08x",
@@ -1057,7 +1057,7 @@ COMMAND_HANDLER(handle_scan_chain_comman
expected_id[2] = '*';
 
command_print(CMD_CTX,
-   "   || || %s |  |  |
  | ",
+   "   %s",
  expected_id);
}
 
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [patch/FYI 2/5] stellaris: avoid chip writes

[David Brownell]

Previously "reading" clock info (and part info) also, as a side
effect, wrote the flash timing register.  Instead, be more safe:
"reading" should only read.  Write paths still refresh timing,
coping with changes the application code may have made.

Also rename the routine which sets flash timing, indicating what
it's really doing; it's got nothing to do with a "mode".
---
 src/flash/nor/stellaris.c |   23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

--- a/src/flash/nor/stellaris.c
+++ b/src/flash/nor/stellaris.c
@@ -345,8 +345,8 @@ static uint32_t stellaris_get_flash_stat
return fmc;
 }
 
-/* Setup the timimg registers */
-static void stellaris_set_flash_mode(struct flash_bank *bank,int mode)
+/* Set the flash timimg register to match current clocking */
+static void stellaris_set_flash_timing(struct flash_bank *bank)
 {
struct stellaris_flash_bank *stellaris_info = bank->driver_priv;
struct target *target = bank->target;
@@ -471,9 +471,6 @@ static void stellaris_read_clock_info(st
stellaris_info->mck_freq = mainfreq/(1 + sysdiv);
else
stellaris_info->mck_freq = mainfreq;
-
-   /* Forget old flash timing */
-   stellaris_set_flash_mode(bank, 0);
 }
 
 #if 0
@@ -714,9 +711,9 @@ static int stellaris_erase(struct flash_
return stellaris_mass_erase(bank);
}
 
-   /* Configure the flash controller timing */
+   /* Refresh flash controller timing */
stellaris_read_clock_info(bank);
-   stellaris_set_flash_mode(bank,0);
+   stellaris_set_flash_timing(bank);
 
/* Clear and disable flash programming interrupts */
target_write_u32(target, FLASH_CIM, 0);
@@ -791,9 +788,9 @@ static int stellaris_protect(struct flas
return ERROR_FLASH_OPERATION_FAILED;
}
 
-   /* Configure the flash controller timing */
+   /* Refresh flash controller timing */
stellaris_read_clock_info(bank);
-   stellaris_set_flash_mode(bank, 0);
+   stellaris_set_flash_timing(bank);
 
/* convert from pages to lockregions */
first /= 2;
@@ -1011,9 +1008,9 @@ static int stellaris_write(struct flash_
if (offset + count > bank->size)
return ERROR_FLASH_DST_OUT_OF_BANK;
 
-   /* Configure the flash controller timing */
+   /* Refresh flash controller timing */
stellaris_read_clock_info(bank);
-   stellaris_set_flash_mode(bank, 0);
+   stellaris_set_flash_timing(bank);
 
/* Clear and disable flash programming interrupts */
target_write_u32(target, FLASH_CIM, 0);
@@ -1156,9 +1153,9 @@ static int stellaris_mass_erase(struct f
return ERROR_FLASH_OPERATION_FAILED;
}
 
-   /* Configure the flash controller timing */
+   /* Refresh flash controller timing */
stellaris_read_clock_info(bank);
-   stellaris_set_flash_mode(bank, 0);
+   stellaris_set_flash_timing(bank);
 
/* Clear and disable flash programming interrupts */
target_write_u32(target, FLASH_CIM, 0);
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [patch/FYI 4/5] stellaris: probe() cleanups

[David Brownell]

Fix potential memory leak:  make sure the per-bank data
structures are only allocated in probe(), and that calling
probe() multiple times is a NOP.  Use it for auto_probe().

Require probe() to have done its thing:  don't make access
routines cope with it not having been called.  Shrink a
bunch of failure paths; and in some cases, correct them.

Don't needlessly insist on a halted target for probe().
---
 src/flash/nor/stellaris.c |  128 ++--
 1 file changed, 42 insertions(+), 86 deletions(-)

--- a/src/flash/nor/stellaris.c
+++ b/src/flash/nor/stellaris.c
@@ -36,8 +36,7 @@
 
 #define DID0_VER(did0) ((did0 >> 28)&0x07)
 
-static int stellaris_read_part_info(struct flash_bank *bank);
-
+static void stellaris_read_clock_info(struct flash_bank *bank);
 static int stellaris_mass_erase(struct flash_bank *bank);
 
 static struct {
@@ -261,15 +260,11 @@ static int stellaris_info(struct flash_b
int printed, device_class;
struct stellaris_flash_bank *stellaris_info = bank->driver_priv;
 
-   stellaris_read_part_info(bank);
-
if (stellaris_info->did1 == 0)
-   {
-   printed = snprintf(buf, buf_size, "Cannot identify target as a 
Stellaris\n");
-   buf += printed;
-   buf_size -= printed;
-   return ERROR_FLASH_OPERATION_FAILED;
-   }
+   return ERROR_FLASH_BANK_NOT_PROBED;
+
+   /* Read main and master clock freqency register */
+   stellaris_read_clock_info(bank);
 
if (DID0_VER(stellaris_info->did0) > 0)
{
@@ -495,7 +490,8 @@ static int stellaris_read_part_info(stru
fam = (did1 >> 24) & 0xF;
if (((ver != 0) && (ver != 1)) || (fam != 0))
{
-   LOG_WARNING("Unknown did1 version/family, cannot positively 
identify target as a Stellaris");
+   LOG_WARNING("Unknown did1 version/family.");
+   return ERROR_FLASH_OPERATION_FAILED;
}
 
/* For Sandstorm, Fury, DustDevil:  current data sheets say IOSC
@@ -535,9 +531,10 @@ static int stellaris_read_part_info(stru
default:
LOG_WARNING("Unknown did0 class");
}
-   default:
break;
+   default:
LOG_WARNING("Unknown did0 version");
+   break;
}
 
for (i = 0; StellarisParts[i].partno; i++)
@@ -554,23 +551,8 @@ static int stellaris_read_part_info(stru
stellaris_info->num_lockbits = 1 + (stellaris_info->dc0 & 0x);
stellaris_info->num_pages = 2 *(1 + (stellaris_info->dc0 & 0x));
stellaris_info->pagesize = 1024;
-   bank->size = 1024 * stellaris_info->num_pages;
stellaris_info->pages_in_lockregion = 2;
 
-   /* provide this for the benefit of the higher flash driver layers */
-   bank->num_sectors = stellaris_info->num_pages;
-   bank->sectors = malloc(sizeof(struct flash_sector) * bank->num_sectors);
-   for (i = 0; i < bank->num_sectors; i++)
-   {
-   bank->sectors[i].offset = i * stellaris_info->pagesize;
-   bank->sectors[i].size = stellaris_info->pagesize;
-   bank->sectors[i].is_erased = -1;
-   bank->sectors[i].is_protected = -1;
-   }
-
-   /* Read main and master clock freqency register */
-   stellaris_read_clock_info(bank);
-
return ERROR_OK;
 }
 
@@ -586,11 +568,7 @@ static int stellaris_protect_check(struc
unsigned page;
 
if (stellaris->did1 == 0)
-   {
-   status = stellaris_read_part_info(bank);
-   if (status < 0)
-   return status;
-   }
+   return ERROR_FLASH_BANK_NOT_PROBED;
 
for (i = 0; i < (unsigned) bank->num_sectors; i++)
bank->sectors[i].is_protected = -1;
@@ -642,15 +620,7 @@ static int stellaris_erase(struct flash_
}
 
if (stellaris_info->did1 == 0)
-   {
-   stellaris_read_part_info(bank);
-   }
-
-   if (stellaris_info->did1 == 0)
-   {
-   LOG_WARNING("Cannot identify target as Stellaris");
-   return ERROR_FLASH_OPERATION_FAILED;
-   }
+   return ERROR_FLASH_BANK_NOT_PROBED;
 
if ((first < 0) || (last < first) || (last >= 
(int)stellaris_info->num_pages))
{
@@ -719,6 +689,9 @@ static int stellaris_protect(struct flas
return ERROR_INVALID_ARGUMENTS;
}
 
+   if (stellaris_info->did1 == 0)
+   return ERROR_FLASH_BANK_NOT_PROBED;
+
/* lockregions are 2 pages ... must protect [even..odd] */
if ((first < 0) || (first & 1)
|| (last < first) || !(last & 1)
@@ -728,17 +701,6 @@ static int stellaris_protect(struct flas
return ERROR_FLASH_SECTOR_INVALID;
}
 
-   if (stellaris_info->did1 == 0)
-   {
-   stellaris_read_part_info(bank);
-   }
-
-   if (s

[Openocd-development] [patch/FYI 5/5] stellaris: comments

[David Brownell]

Someday revisit various issues:  Tempest parts support writing
more than one word at a time; for some target firmware it might
be necessary to save and restore flash IRQ configuration.

Plus swap some undesirable TAB characters with SPACE.
---
 src/flash/nor/stellaris.c |   21 +
 src/flash/nor/stellaris.h |   23 ---
 2 files changed, 33 insertions(+), 11 deletions(-)

--- a/src/flash/nor/stellaris.c
+++ b/src/flash/nor/stellaris.c
@@ -553,6 +553,11 @@ static int stellaris_read_part_info(stru
stellaris_info->pagesize = 1024;
stellaris_info->pages_in_lockregion = 2;
 
+   /* REVISIT for at least Tempest parts, read NVMSTAT.FWB too.
+* That exposes a 32-word Flash Write Buffer ... enabling
+* writes of more than one word at a time.
+*/
+
return ERROR_OK;
 }
 
@@ -640,6 +645,10 @@ static int stellaris_erase(struct flash_
target_write_u32(target, FLASH_CIM, 0);
target_write_u32(target, FLASH_MISC, PMISC | AMISC);
 
+   /* REVISIT this clobbers state set by any halted firmware ...
+* it might want to process those IRQs.
+*/
+
for (banknr = first; banknr <= last; banknr++)
{
/* Address is first word in page */
@@ -726,6 +735,10 @@ static int stellaris_protect(struct flas
target_write_u32(target, FLASH_CIM, 0);
target_write_u32(target, FLASH_MISC, PMISC | AMISC);
 
+   /* REVISIT this clobbers state set by any halted firmware ...
+* it might want to process those IRQs.
+*/
+
LOG_DEBUG("fmppe 0x%" PRIx32 "",fmppe);
target_write_u32(target, SCB_BASE | FMPPE, fmppe);
 
@@ -921,6 +934,10 @@ static int stellaris_write(struct flash_
target_write_u32(target, FLASH_CIM, 0);
target_write_u32(target, FLASH_MISC, PMISC | AMISC);
 
+   /* REVISIT this clobbers state set by any halted firmware ...
+* it might want to process those IRQs.
+*/
+
/* multiple words to be programmed? */
if (words_remaining > 0)
{
@@ -1068,6 +1085,10 @@ static int stellaris_mass_erase(struct f
target_write_u32(target, FLASH_CIM, 0);
target_write_u32(target, FLASH_MISC, PMISC | AMISC);
 
+   /* REVISIT this clobbers state set by any halted firmware ...
+* it might want to process those IRQs.
+*/
+
target_write_u32(target, FLASH_FMA, 0);
target_write_u32(target, FLASH_FMC, FMC_WRKEY | FMC_MERASE);
/* Wait until erase complete */
--- a/src/flash/nor/stellaris.h
+++ b/src/flash/nor/stellaris.h
@@ -53,18 +53,19 @@ struct stellaris_flash_bank
 
 /* STELLARIS control registers */
 #define SCB_BASE   0x400FE000
-#defineDID00x000
-#defineDID10x004
-#defineDC0 0x008
-#defineDC1 0x010
-#defineDC2 0x014
-#defineDC3 0x018
-#defineDC4 0x01C
+#define DID0   0x000
+#define DID1   0x004
+#define DC00x008
+#define DC10x010
+#define DC20x014
+#define DC30x018
+#define DC40x01C
 
-#defineRIS 0x050
-#defineRCC 0x060
-#definePLLCFG  0x064
-#defineRCC20x070
+#define RIS0x050
+#define RCC0x060
+#define PLLCFG 0x064
+#define RCC2   0x070
+#define NVMSTAT0x1a0
 
 /* "legacy" flash memory protection registers (64KB max) */
 #define FMPRE  0x130
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [patch/FYI 3/5] stellaris: remove needless code

[David Brownell]

No point in reading and discarding a status value when fetching
part description data.  Or having that needless "#if 0" code.
---
 src/flash/nor/stellaris.c |   51 
 1 file changed, 1 insertion(+), 50 deletions(-)

--- a/src/flash/nor/stellaris.c
+++ b/src/flash/nor/stellaris.c
@@ -37,7 +37,6 @@
 #define DID0_VER(did0) ((did0 >> 28)&0x07)
 
 static int stellaris_read_part_info(struct flash_bank *bank);
-static uint32_t stellaris_get_flash_status(struct flash_bank *bank);
 
 static int stellaris_mass_erase(struct flash_bank *bank);
 
@@ -335,16 +334,6 @@ static int stellaris_info(struct flash_b
 *  chip identification and status *
 ***/
 
-static uint32_t stellaris_get_flash_status(struct flash_bank *bank)
-{
-   struct target *target = bank->target;
-   uint32_t fmc;
-
-   target_read_u32(target, FLASH_CONTROL_BASE | FLASH_FMC, &fmc);
-
-   return fmc;
-}
-
 /* Set the flash timimg register to match current clocking */
 static void stellaris_set_flash_timing(struct flash_bank *bank)
 {
@@ -473,48 +462,12 @@ static void stellaris_read_clock_info(st
stellaris_info->mck_freq = mainfreq;
 }
 
-#if 0
-static uint32_t stellaris_wait_status_busy(struct flash_bank *bank, uint32_t 
waitbits, int timeout)
-{
-   uint32_t status;
-
-   /* Stellaris waits for cmdbit to clear */
-   while (((status = stellaris_get_flash_status(bank)) & waitbits) && 
(timeout-- > 0))
-   {
-   LOG_DEBUG("status: 0x%x", status);
-   alive_sleep(1);
-   }
-
-   /* Flash errors are reflected in the FLASH_CRIS register */
-
-   return status;
-}
-
-/* Send one command to the flash controller */
-static int stellaris_flash_command(struct flash_bank *bank,uint8_t 
cmd,uint16_t pagen)
-{
-   uint32_t fmc;
-   struct target *target = bank->target;
-
-   fmc = FMC_WRKEY | cmd;
-   target_write_u32(target, FLASH_CONTROL_BASE | FLASH_FMC, fmc);
-   LOG_DEBUG("Flash command: 0x%x", fmc);
-
-   if (stellaris_wait_status_busy(bank, cmd, 100))
-   {
-   return ERROR_FLASH_OPERATION_FAILED;
-   }
-
-   return ERROR_OK;
-}
-#endif
-
 /* Read device id register, main clock frequency register and fill in driver 
info structure */
 static int stellaris_read_part_info(struct flash_bank *bank)
 {
struct stellaris_flash_bank *stellaris_info = bank->driver_priv;
struct target *target = bank->target;
-   uint32_t did0, did1, ver, fam, status;
+   uint32_t did0, did1, ver, fam;
int i;
 
/* Read and parse chip identification register */
@@ -618,8 +571,6 @@ static int stellaris_read_part_info(stru
/* Read main and master clock freqency register */
stellaris_read_clock_info(bank);
 
-   status = stellaris_get_flash_status(bank);
-
return ERROR_OK;
 }
 
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[David Brownell]

On Wednesday 16 December 2009, Carsten Breuer wrote:
> Before i do anything, i want to know if the
> OpenOcd Developers are interested in improving
> the code for better maintainance.

Absolutely.  We're also interested in having other
developers help with that work.  :)

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Øyvind Harboe]

On Wed, Dec 16, 2009 at 9:56 PM, Lennert Buytenhek
 wrote:
> On Wed, Dec 16, 2009 at 09:46:29PM +0100, Øyvind Harboe wrote:
>
>> > for number_of_mallocs:
>> > {
>> >    - fix the file
>> >    - see if it compiles.
>> >    - create a patch
>> >    - send it too you.
>> > }
>>
>> No.
>>
>> - fix a file(including build it)
>> - commit to local git
>
> While I am of the opinion that git is the greatest thing since sliced
> bread, I don't think that it is a good idea to require that people learn
> some VCS they aren't familiar with to contribute to a project.
>
> E.g. if someone is already familiar with quilt, they can do most of the
> local patch management they need without having to learn git (even if
> the latter is a good idea, it should not be required upfront).
>
> In this case, if someone sends a patch series to the list, I don't
> think it should matter which VCS was used to manage that patch series
> during local development.

I didn't mean to say that he had to learn git, but he has set
himself a daunting task to touch *every* file in the system.

He's going to have to do some branch management and rebasing...

Sure there are other tools but git to handle this sort of thing, I just
don't know them and I'm very happy with git.



-- 
Ø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-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [patch/FYI 5/5] stellaris: comments

[Øyvind Harboe]

Are we trying to use doxygen comments for todo items?

Is the syntax in this patch correct?



-- 
Ø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-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Albert ARIBAUD]

Øyvind Harboe a écrit :

> The zy1000 has "infinite" ram w.r.t. small allocations(32 or
> 64mBytes depending on revision), so not checking small
> allocations is *highly unlikely * to cause problems for any
> embedded host with oodles of ram(megabytes).

To be completely honest, it depends. If there's a leak somewhere and 
memory gets lost monotonically, you *might* get failures in allocations 
more frequently than you think.

In fact, finding possible leaks might be more beneficial than checking 
allocs -- after all, by checking failed allocs, we trade an OpenOCD 
crash against an OpenOCD emergency stop, whereas by finding leaks we 
trade an earlier OpenOCD crash against a later OpenOCD crash -- this 
buys us somme working time. :)

Amicalement,
-- 
Albert.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Igor Skochinsky]

Hello Carsten,

Wednesday, December 16, 2009, 9:00:58 PM, you wrote:

>>> The first thing i had to learn was, that it is verry uncommon in
>>> OpenOCD to check the result of malloc.
>> This is a known problem where we gladly accept patches to fix each
>> case.

CB> OK, then i will start to fix all the mallocs
CB> that are handled not correct yet and where
CB> i understand what to do if they fail.

There is an emerging opinion that checking for malloc failures in
application code is counterproductive:
1) it is rarely tested properly, thus almost never works as expected
when allocation does fail
2) it bloats the code, in some case substantially, and obscures the
"real" code flow
3) it's very hard to write a proper rollback algorithm for all
situations
4) if the system is at the stage where malloc fails, there's little
guarantee that your recovery code will work properly
5) many systems just kill the process when the memory is exhausted
instead of returning NULL

http://article.gmane.org/gmane.comp.audio.jackit/19998
http://log.ometer.com/2008-02.html#4.2


-- 
WBR,
 Igormailto:skochin...@mail.ru

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Austin, Alex]

> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Lennert Buytenhek
> Sent: Wednesday, December 16, 2009 2:57 PM
> To: Øyvind Harboe
> Cc: openocd-development@lists.berlios.de
> Subject: Re: [Openocd-development] Codecheck
> 
> On Wed, Dec 16, 2009 at 09:46:29PM +0100, Øyvind Harboe wrote:
> 
> > > for number_of_mallocs:
> > > {
> > >    - fix the file
> > >    - see if it compiles.
> > >    - create a patch
> > >    - send it too you.
> > > }
> >
> > No.
> >
> > - fix a file(including build it)
> > - commit to local git
> 
> While I am of the opinion that git is the greatest thing since sliced
> bread, I don't think that it is a good idea to require that people
> learn
> some VCS they aren't familiar with to contribute to a project.
> 
> E.g. if someone is already familiar with quilt, they can do most of the
> local patch management they need without having to learn git (even if
> the latter is a good idea, it should not be required upfront).
> 
> In this case, if someone sends a patch series to the list, I don't
> think it should matter which VCS was used to manage that patch series
> during local development.
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development

If you're already familiar with Quilt, check out StGit. But, really, I
haven't found any tool that makes it easier to manage patches than Git.
That is, essentially, its purpose.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Øyvind Harboe]

On Wed, Dec 16, 2009 at 10:21 PM, Albert ARIBAUD  wrote:
> Øyvind Harboe a écrit :
>
>> The zy1000 has "infinite" ram w.r.t. small allocations(32 or
>> 64mBytes depending on revision), so not checking small
>> allocations is *highly unlikely * to cause problems for any
>> embedded host with oodles of ram(megabytes).
>
> To be completely honest, it depends. If there's a leak somewhere and memory
> gets lost monotonically, you *might* get failures in allocations more
> frequently than you think.
>
> In fact, finding possible leaks might be more beneficial than checking
> allocs -- after all, by checking failed allocs, we trade an OpenOCD crash
> against an OpenOCD emergency stop, whereas by finding leaks we trade an
> earlier OpenOCD crash against a later OpenOCD crash -- this buys us somme
> working time. :)

We've done leak checks and we fixed a number of major leaks
a long time ago.

There may be leaks, but no *major* leak that we know about at this point.-

-- 
Ø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-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[David Brownell]

On Wednesday 16 December 2009, Lennert Buytenhek wrote:
> While I am of the opinion that git is the greatest thing since sliced
> bread, I don't think that it is a good idea to require that people learn
> some VCS they aren't familiar with to contribute to a project.
> 
> E.g. if someone is already familiar with quilt, they can do most of the
> local patch management they need without having to learn git (even if
> the latter is a good idea, it should not be required upfront).

At least one maintainer is using quilt for his(*) work.
He strongly agrees with that.  :)


> In this case, if someone sends a patch series to the list, I don't
> think it should matter which VCS was used to manage that patch series
> during local development.


(*) Not intentionally sexist here ... it just so happens that's
our current contributor base.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [patch/FYI 5/5] stellaris: comments

[David Brownell]

On Wednesday 16 December 2009, Øyvind Harboe wrote:
> Are we trying to use doxygen comments for todo items?

Sometimes.  I'd be more likely to do so if the issues
were more significant.  Not for random notes.

Right now, my main concern with this driver is that
when I tried to use it to write some data into flash,
it just didn't work.  Fixes for that later.  ;)

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] How to Send Patch Series

[Dean Glazeski]

Hey,

I just tried to send a patch series from my laptop using git send-email and
it doesn't appear that it has shown up on the mailing list.  Is there a way
to properly do the git send-email command?  The command I used was:

git send-email --compose --from="dngl...@gmail.com" --to="
openocd-development@lists.berlios.de" -2

// Dean Glazeski
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Carsten Breuer]

Hi Thomas, hi all


> On a normal, modern operating system, (reasonably sized) mallocs should
> never fail, as the system will start thrashing and killing off processes
> long before malloc() fails.

Well, try:

for (int idx = 0; idx < 255; idx++)
{
 void *p = malloc(0x);
}

and your done.

This is IMO not an argument and only an expectation.
I agree with you, that this problems are not a big issue,
since the allocated space is not large enough to create
really problems.
Nonetheless: Malloc can fail and we have to take care of that.



Regards,



Carsten
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Carsten Breuer]

Hi Øyvind,

>> for number_of_mallocs:
>> {
>>  - fix the file
>>  - see if it compiles.
>>  - create a patch
>>  - send it too you.
>> }
> No.
> - fix a file(including build it)
> - commit to local git

OK...i have to learn something new.
Thanks for the hint.


Best Regards,



Carsten
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Albert ARIBAUD]

Carsten Breuer a écrit :

> Nonetheless: Malloc can fail and we have to take care of that.

Well, yes for the first part, and maybe or even no for the second.

Yes, malloc can fail.

But when it fails, what *can* you do apart from trying to fail as 
gracefully as possible? And failing gracefully is impossible for an 
embedded target cross-debugger.

Amicalement,
-- 
Albert.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Carsten Breuer]

Hi Lennert, hi all,

> While I am of the opinion that git is the greatest thing since
> sliced bread, I don't think that it is a good idea to require that
> people learn some VCS they aren't familiar with to contribute to a
> project.

Thanks for your help.
I will give git a chance and see how it works.
I now some RCS like Subversion, MKS Source Integrity, CVS, Continuus
so hopefully this help a bit.

Best regards,



Carsten

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Thomas Kindler]

Carsten Breuer wrote:
> Hi Thomas, hi all
> 
> 
>> On a normal, modern operating system, (reasonably sized) mallocs should
>> never fail, as the system will start thrashing and killing off processes
>> long before malloc() fails.
> 
> Well, try:
> 
> for (int idx = 0; idx < 255; idx++)
> {
>  void *p = malloc(0x);
> }
> 

That's why I said "reasonably sized". If you malloc() inside a file 
parser, malloc() based on unverified user input, or malloc() huge 
buffers, adding a check is an absolute necessity.

These are cases with a clear action to take on error.

But adding a check to every random malloc(sizeof some_struct) is 
counter-productive. If a small malloc() fails, chances are that your 
error handler will fail, too.

Let the operating system take care of these cases.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Carsten Breuer]

Hi Igor,

> There is an emerging opinion that checking for malloc failures in
> application code is counterproductive:

OK, that is not my point of view ;-).
Writing to a zero pointer is allways "wrong code", even if
we think that someone somewhere would clean up the mess
we have created.

> it is rarely tested
> properly, thus almost never works as expected when allocation does
> fail

Well, you can use Test-Tools like Tessy to get a 100% coverage.
I disagree here.

> 2) it bloats the code, in some case substantially, and obscures
> the "real" code flow

The real code flow ends in nothing. There are embedded CPU's that have
no problem with writing to zero. They just do it. So this is really nice
to search errors. Good luck.

> 3) it's very hard to write a proper rollback
> algorithm for all situations

No. If it is, the code is not well structured.

> if the system is at the stage where
> malloc fails, there's little guarantee that your recovery code will
> work properly

You know the difference betwenn stack and heap ;-).

> many systems just kill the process when the memory
> is exhausted instead of returning NULL

What System?
This is at least  one argument.
If all system would do, than perhaps
you can leave this out. But then you are
not able to clean things like a half written
file or something like that.

Best regards,



Carsten



___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[David Brownell]

On Wednesday 16 December 2009, Thomas Kindler wrote:
> 
> > for (int idx = 0; idx < 255; idx++)
> > {
> >      void *p = malloc(0x);
> > }
> > 
> 
> That's why I said "reasonably sized". If you malloc() inside a file 
> parser, malloc() based on unverified user input, or malloc() huge 
> buffers, adding a check is an absolute necessity.
> 
> These are cases with a clear action to take on error.

Not to disagree with the point that error handling can
be problematic ... but don't forget that for long running
programs such as servers (and "openocd" is a server), even
slow leaks cause serious problems over time.

The near-term implication there is that tracking what
happens with heap allocations -- are they freed when
appropriate? -- is worthwhile.

Personally, I've found it's easier to audit *ALL* uses
of each allocated memory block than to ignore obvious
goofs at allocation time. :)

- Dave

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Nico Coesel]

-Oorspronkelijk bericht-
Van: openocd-development-boun...@lists.berlios.de namens Øyvind Harboe
Verzonden: wo 12/16/09 21:43
Aan: Thomas Kindler
CC: openocd-development@lists.berlios.de
Onderwerp: Re: [Openocd-development] Codecheck
 
On Wed, Dec 16, 2009 at 9:36 PM, Thomas Kindler  wrote:
> Carsten Breuer wrote:
 The first thing i had to learn was, that it is verry uncommon in
 OpenOCD to check the result of malloc.
>  >>>
>>> This is a known problem where we gladly accept patches to fix each
>>> case.
>>
>> OK, then i will start to fix all the mallocs
>> that are handled not correct yet and where
>> i understand what to do if they fail.
>
> On a normal, modern operating system, (reasonably sized) mallocs should
> never fail, as the system will start thrashing and killing off processes
> long before malloc() fails.
>
> (This will be a different story for the Zy1000, of course..)

>The zy1000 has "infinite" ram w.r.t. small allocations(32 or
>64mBytes depending on revision), so not checking small
>allocations is *highly unlikely * to cause problems for any
>embedded host with oodles of ram(megabytes).

On Linux you'll get strange effects when a systems runs out of memory due to 
memory leaks. Google for oom killer and learn Linux keeps working (!) in 
mysterious ways. It took us a while to figure out what was going on exactly.

Nico Coesel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Carsten Breuer]

Hi Amicalement,

>> Nonetheless: Malloc can fail and we have to take care of that.
> But when it fails, what *can* you do apart from trying to fail as
> gracefully as possible? And failing gracefully is impossible for an
> embedded target cross-debugger.

Well, on Windows you get a ugly message box that is
interpreted by the user as "developers don't do there job right".
The other thing is that you have the chance to report
the error to the user. You can probably also send a message
over the network, so that the user see in the telnet session
what's going wrong, .. .

Nonetheless, if most of the developers think that
it is not necessary and there is a vote for "not to check"
and  accept the ugly message box, then it have to be at
least documented at the malloc call.

As i said before, i come from the automotive world
and the "stop at every single error" mentality is the worst
and dumbest scenario. In most cases, there are smarter solutions.

Best Regards,



Carsten
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Igor Skochinsky]

Hello Carsten,

Wednesday, December 16, 2009, 11:57:23 PM, you wrote:

Just one point.

>> 2) it bloats the code, in some case substantially, and obscures
>> the "real" code flow

CB> The real code flow ends in nothing. There are embedded CPU's that have
CB> no problem with writing to zero. They just do it. So this is really nice
CB> to search errors. Good luck.

here I meant the code flow for someone who is reading the source, not the
CPU execution path.

Actually, I think a common emalloc() function that (in the unlikely
event of malloc failure) prints an error message and exits the app is
a better choice than sticking checks everywhere.

-- 
WBR,
 Igormailto:skochin...@mail.ru

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[David Brownell]

On Wednesday 16 December 2009, Igor Skochinsky wrote:
> Actually, I think a common emalloc() function that (in the unlikely
> event of malloc failure) prints an error message and exits the app is
> a better choice than sticking checks everywhere.

Not a bad idea for a near-term fix...

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD Coding (was broken)

[Carsten Breuer]

>> The correct function is selected by the compiler and the overhead
>> is IMO in our area not an issue.
> In embedded developpment, "IMO" can be argued to be not precise
> enough.

Well, we talk about the PC-side of an embedded system.
So we have more then enough horse power here.

The overhead is:

> On typical hardware, the machine-code is two 'load's plus a call:

Take a look at:
http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.4

So this is defently not an issue.

> But then, QT and KDE do not have a requirement to "communicate with
> CPUs for embedded debugging purposes, including watching them
> running, on a not-so-fast serial link".

The "not-so-fast serial link" is the issue here.
If the data comes slow, the CPU is 95% idle.


Best Regards,



Carsten
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Austin, Alex]

Actually, probably not a bad idea for a long-term fix. AFAIK, Posix
OSes will inform you of malloc failures with SIGKILL rather than NULL.
The article on gmane.comp.audio.jackit had some very good discussion
on this point, so emulating that functionality under Windows is probably
a decent way to go.

http://article.gmane.org/gmane.comp.audio.jackit/19998

On Wednesday 16 December 2009, David Brownell wrote:
> 
> On Wednesday 16 December 2009, Igor Skochinsky wrote:
> > Actually, I think a common emalloc() function that (in the unlikely
> > event of malloc failure) prints an error message and exits the app is
> > a better choice than sticking checks everywhere.
> 
> Not a bad idea for a near-term fix...
> 
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Dean Glazeski]

On Wednesday 16 December 2009, Igor Skochinsky wrote:
> Actually, I think a common emalloc() function that (in the unlikely
> event of malloc failure) prints an error message and exits the app is
> a better choice than sticking checks everywhere.

I was tempted to suggest something like this.  It could later be extended to
manage resources, too.

// Dean Glazeski
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Carsten Breuer]

Hi all,

Well, this is really interesting.

If we use this, i think it is necessary
to use even another name and avoid anything
that points to the name "malloc" to avoid
any future discussions about this topic.

Perhaps we should use something like:

void *allocate_or_exit(size);

This would make it perfectly clear what happening
and i have no problem with that. It is fail safe.


Best Regards,



Carsten

Am 17.12.2009 00:34, schrieb Austin, Alex:
> Actually, probably not a bad idea for a long-term fix. AFAIK, Posix
> OSes will inform you of malloc failures with SIGKILL rather than NULL.
> The article on gmane.comp.audio.jackit had some very good discussion
> on this point, so emulating that functionality under Windows is probably
> a decent way to go.
> 
> http://article.gmane.org/gmane.comp.audio.jackit/19998
> 
> On Wednesday 16 December 2009, David Brownell wrote:
>>
>> On Wednesday 16 December 2009, Igor Skochinsky wrote:
>>> Actually, I think a common emalloc() function that (in the unlikely
>>> event of malloc failure) prints an error message and exits the app is
>>> a better choice than sticking checks everywhere.
>>
>> Not a bad idea for a near-term fix...
>>
>> ___
>> Openocd-development mailing list
>> Openocd-development@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/openocd-development
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[Carsten Breuer]

Hi all,


> Perhaps we should use something like:
>
> void *allocate_or_exit(size);

I would also make some defines in types.h:

#define malloc YOU_SHOULD_NEVER_EVER_USE_MALLOC
#define calloc YOU_SHOULD_NEVER_EVER_USE_CALLOC

With this, developers can't use malloc
accidentally.

If it is guarantied, that malloc exits
under linux, we can also just use
a define for that:

#ifdef unix
#   define allocate_or_exit(x) malloc(x)
#elif (defined WIN32)
// Windows code here
#endif  

Of course, we need something for the above define in types.h


Just some thoughts



Carsten

Am 17.12.2009 00:53, schrieb Carsten Breuer:
> Hi all,
> 
> Well, this is really interesting.
> 
> If we use this, i think it is necessary
> to use even another name and avoid anything
> that points to the name "malloc" to avoid
> any future discussions about this topic.
> 
> Perhaps we should use something like:
> 
> void *allocate_or_exit(size);
> 
> This would make it perfectly clear what happening
> and i have no problem with that. It is fail safe.
> 
> 
> Best Regards,
> 
> 
> 
> Carsten
> 
> Am 17.12.2009 00:34, schrieb Austin, Alex:
>> Actually, probably not a bad idea for a long-term fix. AFAIK, Posix
>> OSes will inform you of malloc failures with SIGKILL rather than NULL.
>> The article on gmane.comp.audio.jackit had some very good discussion
>> on this point, so emulating that functionality under Windows is probably
>> a decent way to go.
>>
>> http://article.gmane.org/gmane.comp.audio.jackit/19998
>>
>> On Wednesday 16 December 2009, David Brownell wrote:
>>>
>>> On Wednesday 16 December 2009, Igor Skochinsky wrote:
 Actually, I think a common emalloc() function that (in the unlikely
 event of malloc failure) prints an error message and exits the app is
 a better choice than sticking checks everywhere.
>>>
>>> Not a bad idea for a near-term fix...
>>>
>>> ___
>>> Openocd-development mailing list
>>> Openocd-development@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/openocd-development
>> ___
>> Openocd-development mailing list
>> Openocd-development@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/openocd-development
> 
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Codecheck

[David Brownell]

On Wednesday 16 December 2009, Carsten Breuer wrote:
> If it is guarantied, that malloc exits
> under linux, we can also just use
> a define for that:

As I understand it, ANSI C says it returns NULL when
it can't allocate memory.  Anything else would be
phenominally rude.

For the record, I've never heard of *ANY* runtime
environment where a malloc()/calloc()/... failure
aborts the program.

Such a panic-on-ENOMEM strategy is only appropriate
for layers above malloc()/calloc().


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] How to Send Patch Series

[Øyvind Harboe]

I split the job:

1. git format-patch => produces patch series

2. verify the patch series

3. send it:

git send-email --smtp-server=xxx
--to="openocd-development@lists.berlios.de"  00*

-- 
Ø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-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development