Re: [Openocd-development] 0.4.0-rc1 - cannot do "flash erase_address"

On Wednesday 23 December 2009, Freddie Chopin wrote: > I don't know whether I'm doing that right, but I'm pretty sure it works > that way... > > >> flash erase_adrress 0x800 131072 > > add_usage_text [...] ] > > usage [ ...] > > flash erase_adrress 0x800 131072: command requires more arg

Re: [Openocd-development] [patch/rfc] Add support for multiple-ports on FT4232H

> I could probably do this, but supporting the 4232 is time I can bill to > my company, while driver refactoring is not (yet). Why should the community take on cleanup and refactoring work to support your company's patch? You may have a tiny problem explaining the community why they should accept

Re: [Openocd-development] Cortex A8 status

On Tuesday 22 December 2009, Dirk Behme wrote: > I did some additional tests: > > * I updated to 0.4.0-rc1-dev-1-g4e2b15f (2009-12-23-08:09) > > * I have Beagle A4 and C1. > > * Both show above sticky errors after board "cold" start. I.e. power > up the board, let it wait at U-Boot prompt

Re: [Openocd-development] 0.4.0-rc1 - cannot flash STM32

On Wednesday 23 December 2009, Freddie Chopin wrote: > > One thing to do is disable the auto erase.  Erase the range > > first "by hand". > > It works this way - I hope that this is temporary. Working on fixing the "write_image" code; yes. ___ Openocd-

Re: [Openocd-development] [patch/rfc] Add support for multiple-ports on FT4232H

On Wednesday 23 December 2009, Laurent Gauch wrote: > On Tuesday 22 December 2009, Alex Austin wrote: > > I doubt this is the right way to do things, but it hasn't broken > > anything yet. This is just providing framework support for an adapter > > with reset lines driven by BDBUS instead of ACBUS.

Re: [Openocd-development] 0.4.0-rc1 - cannot flash STM32

On 2009-12-23 03:24, David Brownell wrote: > One thing to do is disable the auto erase. Erase the range > first "by hand". It works this way - I hope that this is temporary. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.

[Openocd-development] 0.4.0-rc1 - cannot do "flash erase_address"

I don't know whether I'm doing that right, but I'm pretty sure it works that way... >> flash erase_adrress 0x800 131072 > add_usage_text [...] ] > usage [ ...] > flash erase_adrress 0x800 131072: command requires more arguments > in procedure 'flash' called at file "command.c", line 637

Re: [Openocd-development] [patch/rfc] Add support for multiple-ports on FT4232H

On Wednesday 23 December 2009, Laurent Gauch wrote: > For All: >   DO NOT ACCEPT TO CHANGE FT2232.c for mixed channels. So his "RFC" plot was successful. :) > For Alex : >   PLEASE CREATE A NEW DRIVER ! Hmm, maybe splitting the ft2232.c code into more manageable chunks would suffice? That's a

[Openocd-development] [patch/rfc] Add support for multiple-ports on FT4232H

> > >/ -Original Message- > />/ From: openocd-development-bounces at lists.berlios.de > > [mailto:openocd- > />/ development-bounces at lists.berlios.de > ] On B

Re: [Openocd-development] [patch/rfc] NOR FLASH: only erase/unlock whole sectors

On Wed, Dec 23, 2009 at 1:47 PM, David Brownell wrote: > On Wednesday 23 December 2009, Řyvind Harboe wrote: >> I do think it might be useful to print actual address >> ranges erased in some reasonably terse and non >> warning format. > > If it's going to be erasing data beyond what it was told >

Re: [Openocd-development] [patch/rfc] NOR FLASH: only erase/unlock whole sectors

On Wednesday 23 December 2009, Øyvind Harboe wrote: > I do think it might be useful to print actual address > ranges erased in some reasonably terse and non > warning format. If it's going to be erasing data beyond what it was told to erase, we deserve at the very least a warning. That's pretty b

Re: [Openocd-development] [patch/rfc] NOR FLASH: only erase/unlock whole sectors

Øyvind Harboe wrote: > Now, there is a small problem you pointed out: that two elf images > that are "too close together" won't work with the flash write > image erase option, but here the user can use flash erase_address > range in one pass and then multiple invocations of flash > write_image, so

Re: [Openocd-development] [patch/rfc] NOR FLASH: only erase/unlock whole sectors

Some background info: The purpose of flash erase_address / flash write_image dammit is to use it from scripts. A bunch of targets, new and old can then be flashed or reflashed with some firmware with trivial scripts that have no conditional code. The scripts do not have to be updated as the elf i

Re: [Openocd-development] [patch/rfc] NOR FLASH: only erase/unlock whole sectors

I do think it might be useful to print actual address ranges erased in some reasonably terse and non warning format. This would help the user learn what flash address_range / write_image erase is doing and should cover your concern as well, I think. -- Øyvind Harboe US toll free 1-866-980-3434 /

Re: [Openocd-development] 0.4.0-rc1 - cannot flash STM32

On Wed, Dec 23, 2009 at 3:24 AM, David Brownell wrote: > On Tuesday 22 December 2009, Freddie Chopin wrote: >> >> flash write_image erase c:\\a.hex >> > auto erase enabled >> > address range 0x0800 .. 0x0800681b is not sector-aligned >> > Command handler execution failed >> > in procedure 'fla

Re: [Openocd-development] [patch/rfc] NOR FLASH: only erase/unlock whole sectors

What flash erase address range does is to a) identify sectors within an address range b) erase all those sectors. There is certainly nothing broken about a) and if I wanted to do b) then there is nothing broken about that either. At most, there could be a non-default option to flash erase_address