On 16/11/2010, at 11:36 AM, Andrew Leech wrote:
> On Tue, Nov 16, 2010 at 12:19 PM, Steve Bennett
> wrote:
>>
>> On 16/11/2010, at 11:15 AM, Øyvind Harboe wrote:
>>
>>> On Tue, Nov 16, 2010 at 2:06 AM, Steve Bennett
>>> wrote:
On 16/11/2010, at 9:27 AM, Andrew Leech wrote:
> H
On Tue, Nov 16, 2010 at 12:19 PM, Steve Bennett wrote:
>
> On 16/11/2010, at 11:15 AM, Øyvind Harboe wrote:
>
>> On Tue, Nov 16, 2010 at 2:06 AM, Steve Bennett
>> wrote:
>>> On 16/11/2010, at 9:27 AM, Andrew Leech wrote:
>>>
Hi all,
I've just found a compiling/usage difficulty with the
On 16/11/2010, at 11:15 AM, Øyvind Harboe wrote:
> On Tue, Nov 16, 2010 at 2:06 AM, Steve Bennett wrote:
>> On 16/11/2010, at 9:27 AM, Andrew Leech wrote:
>>
>>> Hi all,
>>> I've just found a compiling/usage difficulty with the git version on
>>> cygwin. Apparently somewhere between 0.4.0 and m
On Tue, Nov 16, 2010 at 2:06 AM, Steve Bennett wrote:
> On 16/11/2010, at 9:27 AM, Andrew Leech wrote:
>
>> Hi all,
>> I've just found a compiling/usage difficulty with the git version on
>> cygwin. Apparently somewhere between 0.4.0 and mainline (possibly
>> jimtcl?) openocd no longer handles dos
On 16/11/2010, at 9:27 AM, Andrew Leech wrote:
> Hi all,
> I've just found a compiling/usage difficulty with the git version on
> cygwin. Apparently somewhere between 0.4.0 and mainline (possibly
> jimtcl?) openocd no longer handles dos line endings on config files.
> Apparently all my config file
On Mon, Nov 15, 2010 at 1:05 PM, Andrew Leech
wrote:
> On Sat, Nov 13, 2010 at 1:28 AM, Peter Stuge wrote:
>
>>> There's specific HDR and similar commands in svf to define these
>>> paddings.
>>
>>> Some software like UrJtag ignores these commands if they even exist
>>> and figures them out its
Hi all,
I've just found a compiling/usage difficulty with the git version on
cygwin. Apparently somewhere between 0.4.0 and mainline (possibly
jimtcl?) openocd no longer handles dos line endings on config files.
Apparently all my config files of my existing 0.4.0 installation have
dos line endings
On 16/11/2010, at 6:05 AM, Spencer Oliver wrote:
>>
>> This looks like it is heading in the right direction.
>>
>>>
>>> As mentioned above we are currently adding a hack so jimtcl builds inline -
>>> this is fine for the standard configure/make case.
>>
>> Can you explain why you needed -DHAV
This looks like it is heading in the right direction.
As mentioned above we are currently adding a hack so jimtcl builds inline -
this is fine for the standard configure/make case.
Can you explain why you needed -DHAVE_NO_AUTOCONF?
I tried with the latest version of jimtcl and it didn't nee
On Mon, Nov 15, 2010 at 4:35 PM, Peter Stuge wrote:
> Øyvind Harboe wrote:
>> Note that if an image is too big(even if you have multiple
>> back to back chips), you'll now get an error message that
>> no flash chip is found:
>>
>> LOG_ERROR("No flash at address 0x%08" PRIx32 "\n", addr);
>
> I thi
Øyvind Harboe wrote:
> Note that if an image is too big(even if you have multiple
> back to back chips), you'll now get an error message that
> no flash chip is found:
>
> LOG_ERROR("No flash at address 0x%08" PRIx32 "\n", addr);
I think this message is misleading. Can this condition be detected
On Mon, Nov 15, 2010 at 4:07 PM, Peter Stuge wrote:
> Øyvind Harboe wrote:
>> > there are parts of the patch which should be separated out,
>> > because they are not really specific to spearsmi.
> ..
>> > Refactor now, or then?
> ..
>> I haven't seen a proposed design and it seems some time off.
>
Øyvind Harboe wrote:
> > there are parts of the patch which should be separated out,
> > because they are not really specific to spearsmi.
..
> > Refactor now, or then?
..
> I haven't seen a proposed design and it seems some time off.
Fair enough. Could we add some commentary to remind future code
flash programming via flash write_image or gdb load would
produce a bogus error message that the flash chip was to
small.
The solution is to limit the current flash programming
run to the current chip.
Signed-off-by: Øyvind Harboe
---
src/flash/nor/core.c | 10 +++---
1 files changed, 7 i
Note that if an image is too big(even if you have multiple
back to back chips), you'll now get an error message that
no flash chip is found:
LOG_ERROR("No flash at address 0x%08" PRIx32 "\n", addr);
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / I
On Sat, Nov 13, 2010 at 1:09 PM, Peter Stuge wrote:
> Øyvind Harboe wrote:
>> So basically if OpenOCD had some generic support for
>> interfacing to SPI chips via the target CPU over JTAG,
>> then you could build on that for your flash driver?
>>
>> That seems a completely separate feature to your
On Sat, Nov 13, 2010 at 10:17 AM, Øyvind Harboe wrote:
> Going twice...
Merged.
--
Øyvind Harboe
Can Zylin Consulting help on your project?
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 pro
Merged.
Thanks!
On Sat, Nov 13, 2010 at 3:59 PM, Freddie Chopin wrote:
> Hi all!
>
> Very small improvement. Tested on STM32, worst-case speed improvement is
> ~1.5%, best-case - ~3%.
>
> Old one:
>> stm32x mass_erase 0
> stm32x mass erase complete
>> flash write_image c:\\stm32.hex
> wrote 12
On Mon, Nov 15, 2010 at 8:37 AM, Domen Puncer wrote:
> On Sat, Nov 13, 2010 at 13:08, Øyvind Harboe wrote:
>> Does the attached patch fix the problem?
>
> Jup, did the trick.
Merged.
Thanks for testing & excellent reporting!
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US t
19 matches
Mail list logo
