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
__
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: T
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
>
...
> C
Ø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, s
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. ;)
___
Openocd-developm
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 aacc5b583c6415fe8d3e6fc99066d6ef
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
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
Ø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 bl
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
expansion
On Sun, Nov 22, 2009 at 11:04 AM, Andreas Fritiofson
wrote:
> On Sun, Nov 22, 2009 at 9:51 AM, Øyvind Harboe
> 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
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
https://lists.berlio
On Sun, Nov 22, 2009 at 10:17 AM, Øyvind Harboe 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 doxygen
>
> => b
On Sun, Nov 22, 2009 at 9:51 AM, Øyvind Harboe 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 fit on the stack. I
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 `/hom
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
_
On Sun, Nov 22, 2009 at 1:56 AM, Andreas Fritiofson
wrote:
> On Sun, Nov 22, 2009 at 1:13 AM, Zach Welch wrote:
>> Checkout your branch and run 'git rebase master'. That will update your
>> branch against the current master. Then, do the same thing with '-i'.
>> Select the patches to change and
> 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 allign
18 matches
Mail list logo
