Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hi Simon,

You might want to look at TI's wiki pages for DSPLink. We are actually in the process of wrapping some of the DSPLink layer stuff to make it a little easier to use and get started, but it's not ready for prime-time.

I would expect some info to start popping up here over the next few weeks. But unfortunately, the coders/testers are also the wiki editors, so it doesn't always make it to the top of the queue. If you have specific questions, we might be able to answer them more responsively...

-Mike

Hey Mike

Thanks for your quick feedback.

Well, my main interrogation are mainly how to start working on the DSP... In the past, I worked with a TI F2812 DSP and we had some code framework provided by TI. Included was some headers describing the chip used (memory mapping to the registers, defines, etc...). I didn't use DSP/BIOS and I just programmed the DSP straight pipe with my JTAG emulator.

So, I was looking for something similar to use the DSP side of the OMAP. Unfortunatly, I can't find out a good starting point... On the TI website, everything seems related to their EVM. I managed to find a BIOS PSP package that gave me many headers and examples. I think I could start out with that. So, the first step I want to accomplish is use their UART example and load it in the DSP core and get it talking with my PC. I still have a couple of blank spots about how to do that though...

You pointed me out to DSPLink, which is used to communicate stuff between the ARM and the DSP (I think). Not sure how this starts me up...

So, that's pretty much my situation... still floating around with all that

OK. I can get you started on that.

You can connect to the DSP via the OMAP JTAG emulator (such as the XDS510 or the XDS100 from TI) through the debug connector interface on the MityDSP-L138 board (you should have a breakout module for that) and download / debug as you did on the TIF2812 using Code Composer Studio from TI. We support version 3.3, and have also used version 4.0 to also communicate to the DSP.

TI code composer studio (CCS) versions 3.3 and 4.0 only run on windows. Both version use the same back-end compiler tools (TI's "code gen tools", or CGT) and the same back end BIOS. 3.3 uses a TI home rolled GUI, 4.0 is eclipse with a pile of TI customizations to support JTAG level debugging. All of the back-end tools (the BIOS and CGT's) are available for linux, so you can compile on linux if you like. TI has a beta version of CCS 5.0, which is a linux version of the IDE front end for eclipse. At the moment, the linux version is freely downloadable, but it's beta. You need to buy a license of CCS to debug, otherwise it's free (for building images, just not debugging). I can get links for all of that if you need them, but Google should get you there just as easy.

We can supply you with a set of gel files (there are some in the BSP link on our wiki) to get started. Using the canned gel file should allow you to connect to the DSP (while the ARM is up and running) and write/debug code as long as you don't interfere with the ARM memory space or ARM controlled peripherals. So... you'll need to tell the ARM (via modifying the kernel) to not use one of the UARTS if you want the DSP to control it directly. I can help with that if you need it.

Your path is the right way to go. get your code up and running, then (later) you can use the ARM (and DSPLink) to load the DSP code out of NAND or MMC during boot up. DSPLink will also facilitate basic IPC communication (e.g., let the ARM run the network stack for a webserver, let the DSP inform the ARM of it's status, etc.).

Do you have CCS available?

-Mike

Hey,

Yes I have a CC4 Platinum version and a XDS510 USB. I will have to read about gel files since I don't know what they are I saw that there were some on the CD I got from you. I will work from Windows for now and maybe later on I can give a try to CCS 5 on linux.

So, first thing, the ARM is always running right? Everytime I power up the board the ARM boots but what about the DSP core?

Since I want to use peripherals on the DSP side, I'll need to prevent the ARM from using them like you said. Are there peripherals I can't and never will be able to use? I saw that there are two UARTs already used for 1) Profibus, 2) CAN. I guess the third one on the motherboard should be the one I can use. I'll have to check which hardware UART is connected to it.

So, if I want to load some code in the DSP, I create my project in CCS for a OMAPL138 (C674x) and use a target confriguration file for the XDS510? Where does the gel file gets in play?

How can I change the Kernel? I saw the mitydspl138.c file where some peripherals used are described (SPI, I2C, UARTs).

Let's start with that

Yes the ARM always runs. By default, it leaves the DSP powered up but in a reset and "nop" state, so it's basically IDLE but powered up and running.

Right, so for the UARTS, unfortunately, you don't want to allocate the console (UART1) to the DSP. The ARM pretty much needs that for things like u-Boot and, well, for the ARM linux console. The Industrial I/O board does allocate the other UARTS to the CAN bus and the Profibus (well, any RS-485 half duplex bus, so you could use that with a RS-485 level converter, though it's half duplex). What I would recommend doing, seeing as you have an emulator, is using straight old "printf". Messages will get routed through the emulator to your CCS "output" window. As you get a DSPLink framework going, you'll likely route debug I/O through DSPLink to the ARM for logging or routing to the network (or the console), etc.

The gel file provides the CCS debugger framework with information about the memory space for the DSP, it also allows you to write scripts to configure low level DSP peripherals (DDR controller, EMIF settings, clear instruction/memory caches after loading code, etc) when you connect to a target, reset it, load new code, etc. In the case of the OMAP-l138, the DSP side gel file doesn't do a whole lot because the ARM is, for the most part, taking care of the low level house keeping. The TI website and CCS manuals should provide a plethora of information about gel files.

For the MityDSP-L138, the linux device instantiation is performed in the mityomapl138_init() routine in arch/arm/mach-davinci/board-mityomapl138.c. Each device that the ARM / linux OS will manage is registered (with optional "platform data" describing device specific information) there. Registered devices are then matched to their appropriate drivers (if they've been compiled in) and are added to the system. If you need to add/remove devices to be managed by the ARM/linux kernel, this is the file to look at. There are instructions about rebuilding the kernel on the wiki page at this site.

-Mike

Just a quick question before digging in. If I change the kernel, then compile it and load it in the flash but nothing works after, is there always a way to bring back factory stuff?

Actually, we recommend that you load it into RAM (using tftp or nfs load or serial, whatever) and boot using the "bootm" command. This will allow you to test your kernel by just running it out of RAM (after downloading it) without FLASHING it in. There should be mention of the specific u-Boot commands on the kernel wiki page. Let me know if you get stuck.

As long as you don't whack the SPI-NOR below 0x100000 offset, you should be able to get back to u-boot and recover. And even if you manage to whack the u-boot area, there are some tools to recover a completely "bricked" board posted on this site to get you back up and running. That said, it's much more convenient to avoid those scenarios... :^)

Thanks a lot Mike!

I will dive in now and I'll keep you posted when I hit a wall.

When I build in CCS my stuff, do I need a special linker for the mitydsp card?

Another verification : On the mitydsp-l138 motherboard, there are three 50 pins IO expansion slots. Could you confirm that there are no SPI accessible ?

Thanks!

On the Industrial I/O host card, you are correct, neither SPI port that is connected to the OMAP-L138 on the MityDSP-L138F is available on the expansion I/O slots. One is shared with the MII (ethernet ) interface, the other is hooked to the on-board CAN controller. This motherboard is not the best option for developing your own SPI interfaces with the MityDSP-L138 or MityARM-1808 SoM.

However, we do have a SPI FPGA core that could be loaded up and routed to the expansion header, if that is of interest. We could put in multiple additional SPI cores if you needed them.

Otherwise, you may need to use a different host board to get access to the OMAP-L138 SPI ports or modify the one you have and grab the CAN SPI interface lines (jumpers....) for development. Sorry.

-Mike

Hey!

Well it's not that much a big deal. We are working on our own motherboard to connect the SODIMM so we will have access to more stuff. Still, the FPGA SPI core interests me. The only reason why I never talk about the FPGA or try no to get involved with it is because I have no experience (well really small one) with vhdl. If you already have a FPGA SPI core it could be useful since it would give us the ability to use the MUX pinned over SPI for something else (ethernet). Is it trivial to use a SPI core?

I still have one question though. On the other motherboard, the PRO one with ADC and DACs etc... the McBSP 0 and 1 are used to communicate with the DAC/ADC. Based on the MUX of the OMAP, one of the McBSP port is MUXed with MII (ethernet)... How is that possible? Is it because the two ethernet ports are routed to a FPGA ethernet core?

Thanks!