"Peter Stuge" napisał(a):
> Freddie Chopin wrote:
> I was considering this too. I strongly prefer a single file for the
> entire family if possible, but it should not cost very much, if any,
> performance.
But in this situation single file costs performance, so that's not a good idea.
BTW I
Xiaofan Chen wrote:
> > create a "general" cfg file and small dedicated cfg files for every
> > STM32 device available
>
> Yet another solution is to have a generic cfg file with minimum 4KB of SRAM
I think this was the idea.
> but allow user to overwrite the generic config file with bigger wor
On Fri, Oct 29, 2010 at 3:41 AM, Freddie Chopin wrote:
> Of course 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. The structure of the target folder
> could be
On Fri, Oct 29, 2010 at 8:08 AM, Marek Vasut wrote:
>> On Fri, Oct 29, 2010 at 7:57 AM, Marek Vasut
>> wrote:
>> > > Shouldn't this be automatically detected?
>> > >
>> >
>> > yes it should ... i'll send a patch on top of this one once I
>> > figure out how to do it. Is that good enough approach
On Fri, Oct 29, 2010 at 7:57 AM, Marek Vasut wrote:
>> Shouldn't this be automatically detected?
>>
>
> yes it should ... i'll send a patch on top of this one once I
> figure out how to do it. Is that good enough approach for you?
> Or shall we put these on hold until then?
I would definitely lik
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 li
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
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 po
This patch introduces support for Cortex A8 based Freescale i.MX51 CPU. This CPU
has the Debug Access Port located at a different address (0x60008000) than TI
OMAP3 series of CPUs.
i.MX51 configuration file based on OMAP3 configuration file and an email from
Alan Carvalho de Assis .
Signed-off-by
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 o
This patch finally adds support for i.MX51 based Genesi USA EfikaMX smarttop
board.
Signed-off-by: Marek Vasut
---
tcl/board/efikamx.cfg |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
create mode 100644 tcl/board/efikamx.cfg
diff --git a/tcl/board/efikamx.cfg b/tcl/board/ef
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 12
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 depende
On Wed, Oct 27, 2010 at 10:53 PM, Freddie Chopin 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 16kB. With
> std
On Thu, Oct 28, 2010 at 11:12 AM, Spencer Oliver wrote:
> On 27/10/2010 18:50, Øyvind Harboe wrote:
>>
>> On Wed, Oct 27, 2010 at 6:21 PM, Peter Stuge 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
On 27/10/2010 18:50, Øyvind Harboe wrote:
On Wed, Oct 27, 2010 at 6:21 PM, Peter Stuge 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 Stuge
Could they also be ma
Ø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 lit
On Thu, Oct 28, 2010 at 8:42 AM, Peter Stuge 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 thin
18 matches
Mail list logo
