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
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 nev
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
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 i
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 c
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
>> 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 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...
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 ju
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
-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:
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
> bu
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
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++)
> {
> v
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 w
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
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
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 do
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-devel
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
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
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
> -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: [Openo
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
Ø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 ther
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
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 fi
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. :)
__
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/sr
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 +
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
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, i
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 +++---
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.
___
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 opini
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/o
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 rema
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
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 ke
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-dev
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
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 requi
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 sp
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 missin
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
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 al
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
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 understa
>
> 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 coul
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
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/mail
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 conf
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
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 pro
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
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-
>> dev
> 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
> -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:
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 t
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
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 corr
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
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
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 [mailt
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 da
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 us
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 ...
67 matches
Mail list logo
