-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/01/18 01:50, David Riley wrote: >> On Jan 11, 2018, at 5:06 PM, Jiri Kastner <[email protected]> >> wrote: >> >> hi, looking at emails from last few days, maybe is time to do >> something with support for non-arm architecture (PPC, AVR32, >> TriCore, VC4) debugging (BDM, Nexus, OCDS) :) >> http://openocd.zylin.com/#/c/4328/ i collected all those targets >> while i was hounting details about PPC. >
I have almost no experience with development of OpenOCD, but a little low-level experience with JTAG and related debuggers. > Generally in favor, but I don't know how much time I'll > realistically have to contribute at the moment since I'm searching > for new employment. FWIW: > > - DSP56K has had some OpenOCD support for a long time, though I > don't remember if it's mainlined at this point. > > - PPC is *hard*, at least for a lot of the embedded variants. If I remember correctly, PPC debug (at least on the MPC5xx that I used long ago) is done by using the JTAG interface to insert instructions directly into the instruction stream. The concept is simple enough, and very powerful. But the details of which instructions to send will be hard, and as you say there are a /lot/ of variants - including different types of compression on the instruction sets. A key point for PPC work is to consider who will use OpenOCD with the PPC, and which cores will be of interest. It is pretty much gone from the cpu world, and rarely used now in new network equipment where it used to be strong. FPGAs with PPC hard cores now have ARM hard cores or use soft cores. There are some nice industrial and automotive PPC microcontrollers, however. These are used in the car industry and other high-reliability systems - and are almost invariably used by bigger development groups using expensive commercial tools (compilers from Green Hills, debuggers from iSystem, commercial RTOS's, etc.). At the low end you have CodeWarrior toolchain and P&E Micro debuggers. There is little support in gcc and gdb for these kinds of devices, and I can't see there being many people who would want to use OpenOCD with them. If OpenOCD were a commercial development project, I would not expect PPC support to be worth the cost. > > - XTensa (used in the ESP8266 and ESP32) has a branch here: > https://github.com/espressif/openocd-esp32 (and I wouldn't mind > seeing that mainlined) It is - I'd also like to put in a plug for > Coldfire, even if it's been more or less sidelined even before > Freescale changed hands a few times. I had done some initial work > towards Coldfire BDM support a while ago (uh, around 2010 or so) > but it would be long out of date now. > I made a Coldfire BDM interface from an FTDI FT2232 chip built, many years ago. We had a board using an MCF5234 Coldfire microcontroller (if I remember the number correctly) - a very nice chip that we used to replace the fantastic but ageing MC68332. Since the board needed Uart over USB anyway, I put one of these chips on and used its SPI interface to control the BDM of the Coldfire. The Coldfire BDM needed 17 bit transfers - 16-bit of data one way, then 1 bit of error/status the other direction. To simplify things, I just assumed that everything worked and ignored the return bit - then I could send everything in long streams (doing the 16-bit to 17-bit padding on the PC side). Doing it "properly" and checking the return bits would slow down transfers enormously. I only supported enough for writing blocks of data or code to ram and starting the program - that was all I needed to use this for software updates and board programming - and the PC code is all in Pascal. But it was straightforward, and the details were all clearly documented in Freescale's manuals. Another minor target that might be interesting for OpenOCD is the AVR (jtag, SPI programming, and their current single wire debug system). I haven't used AVR's for many years, so I haven't followed their latest efforts. The other interesting device would be RISC-V. I have no idea what the status of that is in OpenOCD, but it seems to be the trendy processor core to use! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJaWHvAAAoJEPy4fZ5YP6apHWwH/AryyRD1TiQRSNwjRmQ1n0Jh YCZpcK19GAeU+JGX7luTpUmgoLfrBYhoKGulgjvQR6dbvAxQMqPoCRFmD1VostGC Z/tdg2F5qpVdUPBC5HzuR1jr6oegNj/RZ53tTPotE3DysMmp3BB4MCGH2+OIcGJq SZZtzD7ZS6O5xEtdGfTChfqo1f2pf5pGpDG7Y5c6C0NNI09XRPIPHPu7o1D4u7xe ZN0Wt5qZyfbysuu2BRzxEKTdNaIcjmia8RCH4ne8EdqIU6HpzAarYymWOV/+aQrv IjzzI0UJQ8KgHc9fFfOYsHfbCJl8A0WAEk3Y9AJmB6UR3GLL5ag8c1mec8O/Po0= =tPgq -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
