Re: [Openocd-development] merging cortex_a8/a9.c and improving Pandaboard config files
On Tue, Mar 22, 2011 at 1:03 AM, Aaron Carroll xaar...@gmail.com wrote: On 21 March 2011 23:45, Øyvind Harboe oyvind.har...@zylin.com wrote: Can anyone think of a good reason why we're duplicating these source files at this point? These were duplicated because I didn't want to break anyone's A8 while getting A9 support up. I think most (all?) of the A9 changes should be correct for A8 too. The Cortex A8 is also very much work in progress, so it will, ultimately, benefit from all efforts being directed to the same source code. I just got a Pandaboard today and ti_pandaboard.cfg is currently using omap3530.cfg, which uses Cortex A8, even if the Pandaboard is a Cortex A9. Huh? Strike that. I looked up the wrong omap.cfg file, which ultimately led me to propose to merge the a8 a9 code, so perhaps not such a bad thing after all :-) -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] cortex a9: merge cortex a9 and a8 code
On Tue, Mar 22, 2011 at 12:22 AM, Tomek CEDRO tomek.ce...@gmail.com wrote: Hello world :-) On Mon, Mar 21, 2011 at 3:00 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: In terms of maintenance we can't really support two files that are so similar, so unless I hear major objections, I'd rather go with this patch and sort out any regressions afterwards. Maybe those two files are similar, but they are targeted for different cpu families that have different quirks to work, so I think they should be kept separated to avoid mess that can show up after some time - usually one more file is not a pain but can make solution more clear and elegant - thats only my opinion, not an objection :-) If you prefer one file, why not name it arm_cortex.c to avoid putting cortex_a9 stuff into cortex_a8 file? :-) cortex a8 and a9 are very similar, so they should be merged and conditional code used + configuration options. cortex m3 is more mature(hence breakage is more of an issue) and much more different so merging *all* cortex code is further down the road. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] cortex a9: merge cortex a9 and a8 code
On Tue, Mar 22, 2011 at 6:22 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: cortex a8 and a9 are very similar, so they should be merged and conditional code used + configuration options. cortex m3 is more mature(hence breakage is more of an issue) and much more different so merging *all* cortex code is further down the road. Aaah, maybe cortex_m.c and cortex_a.c then? :-) Best regards! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] cortex a9: merge cortex a9 and a8 code
On Tue, Mar 22, 2011 at 9:18 AM, Tomek CEDRO tomek.ce...@gmail.com wrote: On Tue, Mar 22, 2011 at 6:22 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: cortex a8 and a9 are very similar, so they should be merged and conditional code used + configuration options. cortex m3 is more mature(hence breakage is more of an issue) and much more different so merging *all* cortex code is further down the road. Aaah, maybe cortex_m.c and cortex_a.c then? :-) Sounds sensible to me. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] cortex a8/a9 debug base
I'm wondering if it would be better to ditch the automatic fixup code and use parameters to target in config script. Default would be to use the automatic detection per ARM's specification. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cortex a8/a9 debug base
Øyvind Harboe wrote: I'm wondering if it would be better to ditch the automatic fixup code and use parameters to target in config script. Default would be to use the automatic detection per ARM's specification. Since auto-detecting the broken devices seems to be problematic, I think that would be a good approach, because it has zero chance of breaking non-affected devices. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cortex a8/a9 debug base
On Tue, Mar 22, 2011 at 12:14 PM, Michael Schwingen rincew...@discworld.dascon.de wrote: Øyvind Harboe wrote: I'm wondering if it would be better to ditch the automatic fixup code and use parameters to target in config script. Default would be to use the automatic detection per ARM's specification. Since auto-detecting the broken devices seems to be problematic, I think that would be a good approach, because it has zero chance of breaking non-affected devices. Sold then... Patch anyone? Wasn't this what was proposed in the first place? :-) Autodetect of a few broken devices would have been sweet, but I suppose we couldn't get away with it this time... -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] ft2232 jtag mips performance
Hi, I am using a ft2232 based jtag device with a mips board and the performance is really terrible: 57344 bytes in 3119.897949s (0.018 kb/s) It seems to work ok in that I can halt, resume, read/write memory etc, but every operation is very slow, halting takes almost 3 seconds. I pulled the code from git and have tried using both libftdi and libftd2xx0.4.16 but there is little difference. The jtag came with a guruplug and although I no longer have the guruplug itself I do recall reflashing the 225k uboot image and it took only a few seconds. Is this expected performance? If not what do I need to do to debug? Andy ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
