Maybe the following example (output is pasted below) can illustrate the issue
a bit better. First I try to flash a 20KB block, then a 21KB block and
finally a 24KB block. Only the blocks of 20 and 24 succeed, because they
happen
to be nicely 4K alligned. All blocks that are not 4K alligned
On Sun, Nov 22, 2009 at 1:56 AM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
On Sun, Nov 22, 2009 at 1:13 AM, Zach Welch z...@superlucidity.net wrote:
Checkout your branch and run 'git rebase master'. That will update your
branch against the current master. Then, do the same thing
Search for alloc_printf(). It is a printf which allocates the
string dynamically. Remember to free it up after you had
finished using it + add error checking and propagation.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
I can no longer build docs when src != build. I believe this is trivially
reproducible and that the breakage is relatively recent(a month
or so).
Or... perhaps I'm missing some tool on my laptop?
make docs
make doxygen
= both fail
make doxygen/latex/refman.pdf
make[1]: Entering directory
On Sun, Nov 22, 2009 at 9:51 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
Do not use variable length arrays. Use malloc().
If you use variable length arrays on the stack that messes with embedded
/ uCLinux hosts.
Only if the embedded host uses a home directory path longer than what
will
On Sun, Nov 22, 2009 at 10:17 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
I can no longer build docs when src != build. I believe this is trivially
reproducible and that the breakage is relatively recent(a month
or so).
Or... perhaps I'm missing some tool on my laptop?
make docs
make
On Sunday 22 November 2009, Øyvind Harboe wrote:
make[1]: *** No rule to make target `doxygen/latex/refman.pdf'. Stop.
Similar happens with src == build...
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
I need to backport some embedded/uClinux/pthread(?) stack
overflow fixes from the sf master branch.
I'll be maintaining a branch at oharboe/v0.3.2 and possibly
pushing this to sf if there is any interest/once it has settled down.
No problems affecting operating systems w/automatic stack
Øyvind Harboe wrote:
Maybe the following example (output is pasted below) can illustrate the issue
a bit better. First I try to flash a 20KB block, then a 21KB block and
finally a 24KB block. Only the blocks of 20 and 24 succeed, because they
happen
to be nicely 4K alligned. All blocks that
Clearly you know more about this problem than I intend to
learn about it :-)
Would it be possible to consider a change in the flash
driver model that would allow the drivers to just deal
with it?
I'm loathe to add obscure and hard to grasp options...
flash write_image unlock erase xxx should
Perhaps more of flash write_image needs to be pushed
into the flash drivers to give the flash drivers enough context?
Some new fn call in the driver with a default implementation?
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
David Brownell identified a few more important sites of non-trivial
amounts of working memory allocated on stack.
Change to dynamic allocation.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
From
On Sunday 22 November 2009, Øyvind Harboe wrote:
David Brownell identified a few more important sites of non-trivial
amounts of working memory allocated on stack.
Correction: linux/scripts/checkstack.pl did that for us. ;)
___
Øyvind Harboe wrote:
Perhaps more of flash write_image needs to be pushed
into the flash drivers to give the flash drivers enough context?
Some new fn call in the driver with a default implementation?
That was my first thought. But then I thought that that would affect all
drivers, so I
David Brownell wrote:
On Saturday 21 November 2009, Duane Ellis wrote:
It is just blindingly fast...
I suspect that many of those speed improvements can be
had even with a CPU-based solution ...
...
Consider a board:
USB -- Cortex-M3 -- level shifting -- JTAG
...
Come up with
No, i tried alot of clock combinations from 1kHz to 1MHz, the clock is not the
issue, i think. The electrical signals a very good (measured witz oscilloscop).
I also tried to clock the target with 5MHz (with the PEEDI) and it works well.
christian
Original-Nachricht
Datum:
I can't seem to find the generic LPC config script work
that was done(but never committed).
What was the story on why it wasn't committed yet?
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
17 matches
Mail list logo
