Stefan, Assuming that the code drop they sent you is the same one they sent me, the little bit of support in openocd for 563xx is actually based on what you have. Given the differences between 563xx and pretty much every other processor in existence, it would probably make sense to fork openocd to support it and get rid of support for other processors in the fork. While other DSPs have x, y, and p RAM, the 24-bit memory alignment is singularly unique.
The benefit to creating/ hacking on a recent fork of openocd versus just using the Freescale- provided version is support for newer and faster debug interfaces and, probably, significantly better code quality, not to mention configuration syntax. I agree about it not being worth trying to port gcc for it again, but gdb56k is pretty handy. Sdcc may be an option, though. I, myself, have a Symphony SoundBite dev kit that I haven't done much with yet. If you're willing to help, I could probably start a decent fork, and maybe we can get the quality high enough to be hosted as a branch in the official repo. Stefan Stenzel <ste...@stenzel.com> wrote: Moin, Thanks for your warm welcome and comments. On 19.07.2010 00:20, David Brownell wrote: >> I think the best approach would be if you could >> provide patches to openocd/master for >> improvements for this architecture. > > Yes, I think it's recognized that the current code > has weaknesses. Blame it on the chip vendor never > having helped merge their support upstream ... As far as I can tell, current shortcomings are: - no proper support of 24 bit memory - misleading support of 8/16/32 bit memory width - no support for memory spaces - only 44 registers instead of 81 supported > Aren't there potentially changes that would > be needed for GCC and GDB to support these cores? That is beyond my scope, but here again, vendor sent me the sources and I would be happy if anyone would request from me them or host them for download. I feel bad having them sit on my harddrive without anyone but me being able to access these. Besides, if someone decides to program DSP56300 in C, he has probably chosen the wrong chip. So gcc for dsp56300 is quite useless, especially the current release that is based on version 1.37. Considering the strange architecture with P:, X:, Y: and L: memory accesses and 24/48/56 bit fractional data types with inherent arithmetic saturation, I think it would be extremely difficult to fully support that in C. So I have no personal interest in GDB, I prefer to use some old Motorola/Freescale tool called ads56300. Freescale declined to provide the TCP protocol it interacts with its command converter server, so I hacked that meself and plan to use it with openocd. No idea if such a thing could be part of official openocd. The main reason for me to do this is that I don't want to depend on some very old parallel port probe that seriously restricts my choice of computers. So I assume my interest in openocd is a bit different from other developers here that seem to be focused on gcc/gdb and arm processors. > Assuming that's true, contact those teams to > get this processor better supported. One option > of course being to work with the existing stuff > that's not yet mainlined (for compatibility). Given > the vendor hacked GCC and GDB a bit already, then > their changes could maybe seed the Real mainlinable > code that eventually needs to be developed. Ask the > vendor what they've done along those lines, and what > they're willing to do... > I'll give it a try, but without much confidence. Stefan _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
