Linux Requirements for ARM Side of the OMAP-L137

Hoffiz

Other Parts Discussed in Thread: OMAP-L137, OMAPL138, OMAP-L138, MIO

Hi,

I have finished a big chunk of my project, the DSP side, using CCS and the latest SYS/BIOS. The next phase is with the ARM and networking. I've been doing a lot of research and would appreciate some guidance from the experts. Some examples would also be appreciated. I'm already trying to run the EMAC loopback form SDI BSL support.

The ARM has a very "simple" task and it is to connect to the network and pass data from and to the DSP. So far I only need to support TCP/IP and DHCP. The more and more I read it seems that the path of least resistance will be following the "Getting Started Guide for OMAP-L137" and installing Linux on the arm and using DSP LINK to control my application on the DSP. The drivers are supported under DSP/BIOS but I don't think it will be a problem to port my working application from sys/bios to dsp/bios.

The only caveat with this approach is the footprint of Monta Vista Linux. I will be constrained to a very small flash memory and it will not be EMIF but SPI or none at all. I'm not an expert with Linux but I doubt I could build the OS small enough to fit the OMAP-L137 arm internal memory. Thoughts? How about using a SPI RAM instead of the EMIF that is present in the EVM-OMAP-L137? Any suggestions on how complex that could be, if I were to still use Monta Vista Linux? My other plan is to write the TCP/IP myself for the ARM, maybe using lwIP or some other OS independent interface.

The NSP and NDK have crossed my research but, I think, only support the DSP and not the ARM. Is that correct?

What other options could you share for running a simple network application on the ARM of the OMAP-L137?

over 10 years ago

0 Sivaraj Kuppuraj over 10 years ago

TI__Mastermind 35645 points

Hi,

Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI.com documents and in the TI Wiki Pages (for processor issues). Be sure to search those for helpful information and to browse for the questions others may have asked on similar topics (e2e.ti.com).

We are working on it and will get back to you on this.

Thanks & regards,

Sivaraj K

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.

--------------------------------------------------------------------------------------------------------

0 Titusrathinaraj Stalin over 10 years ago

TI__Guru** 116100 points

Hi,

The NSP and NDK have crossed my research but, I think, only support the DSP and not the ARM. Is that correct?

Yes, you are understanding is correct and we don't have NDK ARM examples for OMAPL137.

In "nsp_1_10_00_03" release, we have ARM NDK example for OMAPL138 device.

software-dl.ti.com/.../index_FDS.html

C:\ti\nsp_1_10_00_03\packages\ti\ndk\examples\ndk_omapl138_arm9_examples

The only caveat with this approach is the footprint of Monta Vista Linux. I will be constrained to a very small flash memory and it will not be EMIF but SPI or none at all. I'm not an expert with Linux but I doubt I could build the OS small enough to fit the OMAP-L137 arm internal memory. Thoughts? How about using a SPI RAM instead of the EMIF that is present in the EVM-OMAP-L137? Any suggestions on how complex that could be, if I were to still use Monta Vista Linux? My other plan is to write the TCP/IP myself for the ARM, maybe using lwIP or some other OS independent interface.

Running Linux for NDK stuff, is good idea but size constraint matters.

In my understanding, SPI flash is not sufficient to hold DSPLINK binaries,DSP apps, scripts and system binaries etc., so atleast it needs 50 to 60MB size of flash device.
Try to port OMAPL138 ARM NDK example to OMAPL137 NDK ARM project.

0 Hoffiz over 10 years ago in reply to Titusrathinaraj Stalin

Expert 1670 points

Hi Titus,

Thanks once again for your great support. If I could add a few more points to your ranking I would bump to "Master Guru". This is great advice that even after days looking around I had not been able to find. I disqualified the OMAP-L138 code as starting point since the DSP is different but completely forgot the ARM is exactly the same. I think this will be easier than trying to adapt lwIP on the ARM. I'll keep this thread in my notes. Once ported I will post back the source code.

Cheers

0 Hoffiz over 10 years ago in reply to Hoffiz

Expert 1670 points

Hi Titus,

I think a need a little help from you to make sure I'm not screwing up any low level drivers. This is what I have done. I'm able to import and build the NSP nsp_1_10_02_09 arm omapl138 Hello World example. I did it just to make sure that at least the examples builds with out any issues.

I then create a copy of the project renamed it to 137 and started porting the code. First few things were to: inside Build Settings, under CCS General, to pick my EVM and connection. I then started working on the driver. To do so I copied into my project folder the driver for the omapl138, keeping the same structure, drv/inc etc. This is the driver in the nsp_1_10_02_09.

I then did a compare of the NDK 2.0.0 which includes the omapl137 dsp side as a guide. I was able to confirm that the inc folder for both are equal. Both means ndk 2.0.0 omapl137 and nsp 1.10.02.09 omapl138.

Well there was a difference in

C:\ti\ndk_2_0_0\packages\ti\ndk\src\hal\evmomapl137\eth_omapl137\inc\tistdtypes.h

it was missing the following definition:

#if defined(_TMS320C6X) || defined(__TMS470__)

I think that is expected if the driver was meant only for the DSP.

Then onto the source: I did find a few difference, mostly printf instead of DEBUG print, the definition of

#if defined(__TMS470__) I guess it is expected since both the 137 and 138 have the same ARM. Besides that nothing stand out as hardware specific.

cls_mio.c should be

static Uint32 macsel = RMII;

per ndk 2.0.0

and beside that I did not change anything else on the drv folder.

I added my project drv folder to CCS and try compiling to make sure everything is right, and beside having to add the inc folder I ran into only one error.

"../drv/ethdriver.c", line 280: error #137: struct "_pdinfo" has no field "PBMQ_rx"

which I fixed by changing by commenting the ifdef in nimu_eth.h

after that the build is successful.

I could instead just add the definition to my project but for now I wanted to make sure things, at least build.

From this point forward and assuming you don't see any clear dumb mistakes. How do I point the NDK to my build driver?

0 Titusrathinaraj Stalin over 10 years ago in reply to Hoffiz

TI__Guru** 116100 points

Hi Hoffiz,
OMAPL137 and OMAPL138 memory mapped registers are mostly common.
Right now, are you getting any build error ?
So far, I didn't see any wrong step from which you followed.

0 Hoffiz over 10 years ago in reply to Titusrathinaraj Stalin

Expert 1670 points

Thanks Titus. No at this point I just wanted to consult to see if I'm doing something wrong. You have answered my original questions and that is that, I won't be able to run Linux on the ARM without memory. My best options sounds like it will be the NDK or using something like lwIP. I think the NDK is probably meant for the same reasons as lwIP. A light, Texas Instruments, developed network stack. Although I'm running into some issues I will spawn them into new a new threads.

Basically there are 3 things I need some help but I think each deserves its own thread, please advise if you disagree:

1-) port the omapl138 arm NDK support from the latest version of NSP to support the omapl137 and run the examples
2-) override the auto-generated linker from SYS/BIOS.
3-) best way to communicate between the ARM and the DSP while both are running SYS/BIOS

I will probably spawn the 1-) and wait for your call on 2 and 3

Processors

Processors forum

Linux Requirements for ARM Side of the OMAP-L137