• Locked Locked
  • Replies 17 replies
  • Subscribers 30 subscribers
  • Views 2251 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux support for dev tools

seantellis
Prodigy 40 points

As a Linux user, I would ask if there is any support for Linux as the host OS for the evaluation kits?

EDIT: More information on what I mean.

The EKK-LM3S811 board is the one that has my attention: http://focus.ti.com/docs/toolsw/folders/print/ekk-lm3s811.html

We should be able to create executables under Linux fairly easily using gcc for ARM, or RVDS, but we would need a way of uploading the compiled images to the board via the USB interface under Linux.

The software that comes with the board lists Windows as a requirement.

Having now done some searching around in the schematics and with Google, this does not sound too far-fetched.

The board has a FTDI FT2232C USB IC on board, and this has support at the USB driver level under Linux using libftdi and libusb. This eliminates one hurdle.

In order to develop a Linux loader, the developer would need to determine what sequence of commands to send to the FTDI chip to operate the JTAG interface correctly.

Post edited by: seantellis, at: 2006/10/11 08:26

Post edited by: seantellis, at: 2006/10/11 09:07

  • Intellectual 470 points
    I mentioned something about this in another thread - basically, it is possible for us to do this in linux if we use a small closed-source proxy driver.

    The JTAG details of the Cortex M3 core are published on the Arm web site. But the JTAG details of the particular Stellaris USB interface are based on proprietary information. However, Luminary will share the Windows DebugLib source if you agree to non-disclosure. This means you simply have to port the JTAG code to linux (should be easy because there is already a good linux USB driver), then isolate the JTAG driver in a binary-only format for redistribution.

    This doesn't stop you from giving it away for free in a binary form, and much of the supporting code can still be open source.

    This distribution model is currently being used in the msp430 family. Google "msp430-gdbproxy" for info.

    Eric
  • Prodigy 180 points
    It might be a better to extend an already available "gdb-server" with Cortex-M3 support as a full with open-source solution. A closed source "proxy" is of cause o.k. for a quick/interim solution but as far as I know the the debug-interface of the Cortex-M3 and the flash-programming of LMI-devices is fully documented so there is no real need for a closed source to preserve "secrets" of the manufacturer. A full open-source solution will have better exceptance and better support since a lot of people can review the code and submit patches to fix bugs.

    I have already mentioned OpenOCD in another thread and think it would be a good idea if OpenOCD could be extended with Cortex-M3 support. There are a lot of features already available in OpenOCD which can be used:

    - (very) low-level access to JTAG-hardware ("Wigglers" and FT2232-based interfaces). Multiplattform (MS Windows, Linux, BSD/Mac OSX). I suppose the JTAG-hardware on the LM3S811-Eval-Board is nothing special compared to the other FT2232-based interfaces. All of them use the "JTAG-feature" of the FTDI-chip and just differ in the way the the GPIOs are used i.e. for the reset-line(s). OpenOCD offers config-options for this and an additional "layout" can be added easily.
    - GDB-server
    - Telnet-server
    - Framework for flash-programming

    Of cause there is still a lot of work to do for Cortex-M3 debug-support and flash-programming routines for the LMI-devices. But it should be rather easy for the developers of the DebugLib to add this features to OpenOCD and submit patches to the OpenOCD maintainer.

    Martin Thomas
  • Intellectual 470 points
    >the debug-interface of the Cortex-M3 and the
    >flash-programming of LMI-devices is fully documented
    >so there is no real need for a closed source to >preserve "secrets" of the manufacturer.

    True, but I thought we were talking about re-using the USB JTAG emulator built-in to the Dev boards.

    If you want to use a different JTAG emulator then you're right that we don't need to make it closed source.

    By the way, I forgot to mention that Luminary has a Bootstrap Loader (BSL) that can program the chips and they recently introduced an app note on it. We're still waiting for some of the files to be released, but we should be able to write open source programs that program the chips using the BSL. But there won't be any debug support this way (single-step, breakpoints, etc).

    Eric
  • Prodigy 180 points
    The JTAG-hardware integrated in the evaluation-board is based on the FT2232-IC from FTDI (www.ftdichip.com) which offers basic support for the JTAG-"SPI" by MPSSE commands. The IC is also the "core" in other JTAG-interfaces (i.e. from Amontec, Olimex) and OpenOCD already supports FT2232-based hardware. I currently don't know any other open-source software (gdb-server) which offers support for FTDI2232-MPSSE-JTAG. With OpenOCD 106 the eval.-board can already be used as JTAG-hardware for external controllers which are already supported by OpenOCD (i.e. ARM7TDMI, not tested myself but mentioned in the SVN changelog). Basicly there is no difference in accessing the JTAG-interface of the on-board LMI-controller or external controllers - at least as far as I understand the schematic of the evaluation-board. The "dirty work" like low-level access to the FTDI-chip thru the USB-drivers and handling of the JTAG state-machine are already implemented ("multiplattform"), the gdb-server framework is already done too. "Only" the special handling for the Cortex-M3 is missing.
  • Intellectual 470 points
    I'm not very familiar with very low-level programming of JTAG ports, so I'd have a hard time of it even with the docs that I've seen. I wondor if we could interest Dominic (OpenOCD author) in helping with this port?
  • Intellectual 470 points
    Sorry about the double post. I hit back on my browser and it posted my message again.

    Post edited by: englere, at: 2006/10/25 21:53
  • Prodigy 180 points
    I have got an e-mail from someone who is working on the extension for Cortex-M3-support in OpenOCD. He uses the 811-eval.-board for tests. He is also in contact with Dominic Rath so OpenOCD should support Cortex-M3-debug and flash-programming for the LMI controllers soon (hopefully).
  • Intellectual 470 points
    OpenOCD should support Cortex-M3-debug and flash-programming for the LMI controllers soon

    Cool! Please post here when you have more information. This is an important milestone for the Stellaris devices to allow linux software development.

    Eric
  • Prodigy 40 points

    That's great. I have been reading around on this topic and was gradually gravitating towards OpenOCD as a starting point. It's good to know that better minds than mine are taking the same path.

    The "proprietary" nature of the JTAG specs should be a non-issue - the 811 datasheet says:

    For detailed information on the order of the input, output, and output enable bits for each of the GPIO ports, please refer to the Stellaris Family Boundary Scan Description Language (BSDL) files, downloadable from www.luminarymicro.com.

    Unfortunately, I haven't managed to find them on the site anywhere.

    Also, as far as I can glean (I am no JTAG expert by any means) the JTAG controller in the 811 starts up in a mode which effectively grants access directly to the M3 core, so if we can drive most things from there, we may be OK, at least to start with. Again, from the spec:

    The LMI JTAG controller works with the ARM JTAG controller built into the Cortex-M3 core. This is implemented by multiplexing the TDO outputs from both JTAG controllers. ARM JTAG instructions select the ARM TDO output while LMI JTAG instructions select the LMI TDO outputs.

    The basic minimum functionality we would need is a way to program the flash in the device via JTAG. I understand that you can do this via address-port bit-banging if you have access to the flash control lines, although the more usual way to do it is to program the on-board SRAM with a bootloader program, which itself manages the interaction with the Flash. SRAM loading strikes me as simpler than Flash loading - it has less control lines to worry about.

    I don't know if this is what OpenOCD typically does for flash loading - I am still in the reading stage and my spare tinkering time seems to evaporate terrifyingly fast these days.

  • Prodigy 30 points
    As Martin already said, support for the Cortex-M core is currently being added to the OpenOCD. Magnus Lundin, who also contributed the AT91SAM7 flash code, started working on this some time ago, and last I heard was that he's progressing nicely. I don't have a LMI board myself and can't work on this therefor, so it's all up to Magnus. I'll put an announcement on the webpage once there's something usable.

    The documentation for the Cortex-M debug facilities seems to be quite good, and they're available to everyone from the ARM webpage (after registering, iirc).

    Regards,

    Dominic
  • TI__Expert 4180 points
    That's great news Dominic! If you (or Magnus) need anything from us, don't hesitate to ask.

    Eric

    Post edited by: LMI Eric, at: 2006/11/05 11:41
  • Prodigy 30 points
    Magnus just committed his code to the OpenOCD SVN repository at svn://svn.berlios.de/openocd/branches/cortex-m3/ (http://svn.berlios.de/svnroot/repos/openocd/branches/cortex-m3/ if you can't use the svn protocol).

    If you're interested do a checkout from one of these urls, and build the OpenOCD as described at http://openfacts.berlios.de/index-en.phtml?title=Building_OpenOCD

    For now, the Cortex-M3 code is going to live in a branch of its own, until it received some testing so we can start merging it back into mainline.

    There's a OpenOCD development mailinglist: http://developer.berlios.de/mail/?group_id=4148
    If you're interested in working on the OpenOCD, consider joining this list, as it makes communication among the developers a lot easier.

    Best regards,

    Dominic
  • Prodigy 40 points
    Well done Magnus. I ordered a board on spec on Friday, and it arrived this morning, all the way across the Atlantic.

    I'll therefore perform my duty as guinea pig.

    Edit: I now have a "hello world" app compiled and flashed, and I'm off to bed. Film at 11.

    Post edited by: seantellis, at: 2006/11/08 18:03
  • Prodigy 20 points
    Here is a Window tool for remotely flashing a target connected to a Linux box. The openocd source has been modified to support vFlashErase, vFlashWrite, vSram2Flash, vResume, vResetOn and vResetOff. These are the functions used by the Window client. The Linux sources are available, but the Window sources need my customer's approval.

    http://linnix.com/ocd
  • Prodigy 10 points


    Post edited by: kate, at: 2007/06/28 13:10
  • Intellectual 470 points
    Sorry for the confusion. Only the DebugLib source and the programming code inside the USB chip is proprietary. Of course the USB chip itself is a pretty well-documented chip from FTDI. And the circuit for this board is public.

    It's my understanding that the Stellaris chips are fully documented in regards to debugging, but that may depend on how you define "fully". They have documented enough to allow open debugging protocols to work and that's good enough.

    If you want an open debugging solution you should check into OpenOCD. That has support for these USB dev board devices, and I think it will work under linux and Windows.

    I don't see much advantage in using a Wiggler since you have a built-in USB debugging emulator, but I guess it should work.

    Eric