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 [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
