On Sunday 10 January 2010, richard vegh wrote:
> Unfortunately I don't use git.
You don't need to use "git" to create usable patches. If
two trees are clean,
diff -NaurP tree1 tree2
will generate a better patch. (And if they're not clean,
it's mostly a case of trimming down the "diff" output... or
coming up with a decent list of exclusions.)
> Isn't it possible that you apply the changes with simple "patch -p1 <
> filname.patch" on your working copy,
Make that "patch -p2" ... that's the first problem! Needing "p2"
is unusual; "p1" is widespread, "p0" less so.
Also, non-unified diff syntax causes confusion.
Comments on the new config files:
- Don't bother parameterizing the ETM TAP ID; ARM fixes that ID.
But name it right: that's an *ETB* TAP, not one for an ETM.
- Why those "force an error..." comments when you're not actually
forcing any error??? Are those TAP IDs wrong?
- Don't bother passing "-ircapture 0x1 -irmask 0xf", that just
means "use the defaults", which can be left unsaid.
- There is no "-variant arm926ejs".
- Don't make an lpc3250 target config depend on a particular
JTAG adapter for one board (Hitex stick) using it!!
- Your "reset-start" event is mostly "reset-init" stuff. Split
it in two parts ... reset-init is board-specific.
- There should be a real "reset-start" handler, in the target
file, setting up for the 32KHz reset clock ... see the User's
guide, there's an example of how to set that up. If you make
the "reset init" handler update clocking, it can also turn on
a faster JTAG clock.
And you should also hook up the ETM and ETB; "ti_dm355.cfg"
gives one example of how to do that, maybe you can copy/paste.
Even if it doesn't work so well yet, One Day It Will. :)
- Dave
> then make a diff or commit it? The
> lpc3180.c has the only file what has changed and 3 new files are added.
>
> Richard
>
> On Sun, Jan 10, 2010 at 8:27 PM, Øyvind Harboe <oyvind.har...@zylin.com>wrote:
>
> > "Is there a chance you could use "git diff"? I don't know if I'll
> > be able to apply and review this patch easily tomorrow...
>
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
