Hi Paul,

Am 16.03.2015 um 13:25 schrieb Paul Fertser:
> On Mon, Mar 16, 2015 at 12:55:24PM +0100, Andreas Färber wrote:
>> I would appreciate if the following configs could still be considered:
>>
>> XMC1000 - partially +2, but updated with a minor change
>> XMC4000 - updated accordingly; wouldn't object to flash support either
> 
> Sure. Can you probably fix the flash driver to work on hardware you
> have? I'm feeling a bit uneasy to merge a driver that's "almost
> working" but not quite. 

Not really. The register Jeff is checking has a documented default of
xxxxxxxx, so not sure what to do. He wanted to look into it but either
hasn't found time or at least no new insights yet.

However, if the target and board configs were good to go now, then Jeff
would no longer depend on my preceding patches or me interfere with his.

>> FM4 - waiting for review, working best with new CMSIS-DAP
> 
> If you're talking about http://openocd.zylin.com/#/c/2190/ here, I'm
> afraid it's impossible to merge. I've tried to contact the author in
> private and he replied that he agrees with me but doesn't really plan
> to work on it. The current patch is plain offending, IMHO.

No, I'm referring to my target and board configs

http://openocd.zylin.com/#/c/2569/
http://openocd.zylin.com/#/c/2570/

which didn't get any review since Mar 01.

Since it's called on-chip debugger, not flasher, there should be no hard
dependency on flash support for targets added.
I started looking into a proper fm4 type 1 flash driver, but time is a
limiting factor.

>> Getting new "harmless" configs accepted more quickly would greatly
>> facilitate working with multiple boards and enable better collaboration.
> 
> I understand. OTOH, reviewing configs usually helps to understand more
> about the hardware and to get maintainable code upstream. I do not
> think it'd be nice if we had less strict rules for the config files,
> as they're part of the project as well.

Sure, just getting that review happening would be nice. I've +1'ed the
LPC800 patch for instance after testing, but won't +1 a config whose
numbers I can't verify as a contributor. So if coding style is okay and
the required pieces of info are there for basic debugging, then for you
as a maintainer an unverified TAP ID or lack of own testing
(unrealistic!) shouldn't keep a config from getting merged IMO.

I have even more boards around with local openocd.cfg files (e.g.,
vf610, ifc6540, Mustang, Seattle), but I won't feel motivated posting
more patches when previous cleaned-up ones are just lying around in
Gerrit and making no progress towards master.

Cheers,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to