However, I've always thought that OpenOCD somehow finds the amount of RAM
that is available on the chip and will not allocate more than is possible?
Nope. There is no code in OpenOCD to figure this out.
Perhaps it would be a good idea for some target family scripts
to have some required
Øyvind Harboe wrote:
Perhaps it would be a good idea for some target family scripts
to have some required options, such as amount of RAM
for chip? Perhaps with a default to the minimum possible
amount of ram.
Makes sense. I think in general it would be nice to tidy a little in
tcl/target/ -
On Thu, Oct 28, 2010 at 8:42 AM, Peter Stuge pe...@stuge.se wrote:
Øyvind Harboe wrote:
Perhaps it would be a good idea for some target family scripts
to have some required options, such as amount of RAM
for chip? Perhaps with a default to the minimum possible
amount of ram.
Makes sense. I
Øyvind Harboe wrote:
Perhaps it would be a good idea for some target family scripts
to have some required options, such as amount of RAM
for chip? Perhaps with a default to the minimum possible
amount of ram.
Makes sense. I think in general it would be nice to tidy a little in
On 27/10/2010 18:50, Øyvind Harboe wrote:
On Wed, Oct 27, 2010 at 6:21 PM, Peter Stugepe...@stuge.se wrote:
Spencer Oliver wrote:
Having a bit of a tidy up and found the src to the various ram loaders
i have written over the years - no objections i will commit.
Acked-by: Peter
On Thu, Oct 28, 2010 at 11:12 AM, Spencer Oliver s...@spen-soft.co.uk wrote:
On 27/10/2010 18:50, Øyvind Harboe wrote:
On Wed, Oct 27, 2010 at 6:21 PM, Peter Stugepe...@stuge.se wrote:
Spencer Oliver wrote:
Having a bit of a tidy up and found the src to the various ram loaders
i have
On Wed, Oct 27, 2010 at 10:53 PM, Freddie Chopin freddie_cho...@op.pl wrote:
Hi!
Someone has asked me for help with using OpenOCD + STM32F100 (8kB of RAM).
After some time I've come to conclusion that the problem was caused by
incorrect workareasize value, which in stm32.cfg is defined to be
On 2010-10-28 19:53, Andreas Fritiofson wrote:
We should probably change it to the least common denominator within
the family, which is 8kB (maybe even 6?). Definitely, if you don't see
any significant reduction in flashing speed after reducing the
workareasize (8kB vs 2kB). That's likely
On 2010-10-28 20:15, Freddie Chopin wrote:
I'll try to check the flashing speed with various workareasizes later.
_WORKAREASIZE 0x4000 (16kB)
Start address 0x8000130, load size 129296
Transfer rate: 8 KB/sec, 12929 bytes/write.
_WORKAREASIZE 0x1000 (4kB)
Start address 0x8000130, load size
This patch finally adds support for i.MX51 based Genesi USA EfikaMX smarttop
board.
Signed-off-by: Marek Vasut marek.va...@gmail.com
---
tcl/board/efikamx.cfg |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
create mode 100644 tcl/board/efikamx.cfg
diff --git
In this patch, I introduce the use of -variant parameter, so I can adjust the
debug_base accordingly.
So far, only the OMAP3530 and AM/DM37x CPUs, which utilize the Cortex A8 core
are supported by OpenOCD and both of these use the same Cortex A8 Debug Access
Port address (0x54011000).
There are
Freddie Chopin wrote:
another solution would be to create a general cfg file and small
dedicated cfg files for every STM32 device available (currently 89) -
these would use (include) the general cfg.
I was considering this too. I strongly prefer a single file for the
entire family if
Marek Vasut wrote:
In this patch, I introduce the use of -variant parameter, so I can
adjust the debug_base accordingly.
This seems completely wrong to me. I think this logic should just
stay in Tcl. So if anything, you would add a parameter for dap_base.
//Peter
Shouldn't this be automatically detected?
--
Ø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
14 matches
Mail list logo
