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

Hi Matt,

The error messages you are getting are from the kernel module files not being compiled against the same version of the kernel. Newer filesystems have udpated kernel module files (the ones on the wiki are admittedly pretty old). You can also rebuild them against your kernel version using the source code for the drivers in the MDK release.

What version of the kernel are you using (the one preloaded on the module or from an MDK?)?

-Mike

Hi Mike,

If I understand what I am doing correctly, I am using version 2.6.34-rc1 and I got the kernal from git://support.criticallink.com/home/git/linux-davinci.git.

Thanks,

Matt

Hi Matt,

There are several branches on our git server. The "master" is somewhat older, which is your 2.6.34-rc1. The newer MDKs use different branches. Most use the mitydsp-linux-v3.2 branch. You can check that version of the kernel out for building, etc., by doing:

user@build> git checkout -b mitydsp-linux-v3.2 origin/mitydsp-linux-v3.2

You can use whichever branch you prefer, but later kernels generally have more features, particularly in the area of USB device support.

If you want to rebuild the kernel modules for a specific branch or kernel configuration, check out the instructions here.

Sorry for the delay in the response.

-Mike

Ok, thanks Mike. I'll be sure to check out the newer branches. I was able to get fpga_ctrl to load using the uimage from the MDK folder.

I had a few more questions about getting the screen to work.

I can't seem to be able to get the FPGA DONE LED light to come on, I noticed our FPGA ended in x45 and followed the more specific commands on your wiki but I'm still having trouble. First thing I noticed is the FPGA bin files I'm getting are all around 0x71544 bytes which seem to be smaller than what I should expect from an x45 bin file? I've been mostly trying

TFTP 0xc0700000 serverIP:file.bin
loadfpga 0xc0700000 0x170000

after running this I don't get any error messages, but the FPGA DONE led isn't on.

And the second thing is minor, but it seem that our board says revision b on it, does that sound correct, I kinda expected to have the newest revision of the mitydsp board.

Thanks

Matt

Edit

The board acually says REV A, not sure if it matters.

Hi Matt,

All of the images on the example site are for an LX16, which (I thought) was the standard size FPGA for modules delivered with the Industrial I/O DevKit boards. The images for the LCD on the wiki page are for LX16 based modules. So you are right, the images are too small for the LX45, which is why the DONE light isn't turning on. We'll need to get you a build for the LX45 to support the LCD. The source code for the build is in the MDK download under examples/industrial_io/fpga.

When you refer to the "board number", are you looking at the System on Module (the MityDSP) or the Industrial I/O host board (the mother board)? Can you enter the entire number you are reading?

-Mike

I guess now is a good time to ask, I'm not sure industrial I/O devkit or the PROFIBUS Development Kit, or if there is even a difference between to two. This question came up before and I guess we might as well just ask the expert.

The board number I'm looking at is the MityDSP board, it says
90-000105R-4_RevA
And the S/N is 121890.

I did look in the MDK under examples/industrial_io/fpga for bin files to try and saw the source code, I guess I need to build my own bin though?

Thanks,

Matt

It's the same thing. It got branded with two names early on. Profibus really only works with the MityARM-1810, as there is a licensing restriction on the PRU microcode that runs the profibus stack. You can evaluate it using the other processors (OMAP-L138 or MityARM-1808), but you need to use an 1810 to field units with the TI provided Profibus stack. We generally use the term Industrial I/O board to avoid implying there is a production qualified Profibus stack for non-1810 modules.

The number of interest is really the "dash" number (the -4_RevA). You have 4th "generation" board, which is fairly new. Boards normally get a new "dash" number if anything on the copper is modified. We had a couple of revisions early in the life cycle of these parts.

You can build it, or if I get a moment I can try to build it for that configuration.

-Mike

Hi Matt,

Did you get through this, do you still need assistance?

-Mike

Hi Mike,

Last week I didn't really have time to work on it, this week I'll know if I need more assistance.

-Matt

Ok good news! I got the FPGA bin files needed so that the FPGA ready light comes on. The not so great news is I can't get anything to show up on the monitor connected to the industrial_io board.

I'm following the instructions from:
http://support.criticallink.com/redmine/projects/arm9-platforms/wiki/LCD_configuration

It doesn't seem to matter whether I enter the i2c commands at u-boot or linux, either way I can't get the monitor to come out of standby mode.

The VHDL code is from the MDK/examples/industrial_io/fpga/vhdl/
The image is from MDK/images

@mityomapl138:/var/volatile/tmp# fbset

mode "640x480-19" # D: 7.895 MHz, H: 9.299 kHz, V: 19.055 Hz
geometry 640 480 640 480 16
timings 126667 100 13 2 2 96 4
accel false
rgba 5/11,6/5,5/0,0/0
endmode@

Thanks,
Matt

Hi Matt,

If you are trying to use the DVI connector, you need to use the FPGA image that was built to run with the DVI interface and not the LCD interface. The builds are different as the clock rates and pin-outs/routing are not the same. Which FPGA image are you using?

-Mike

Hi Mike,

Yes, I am using the DVI connector. The FPGA image I am using is one I generated for the x45 FPGA from the source code in examples/industrial_io/fpga. I though this code was for the vision framework kit and would have support for DVI, but is these is a better file I'm be more than happy to use it.

Thanks,

Matt

Hi Matt,

Are you using a wide screen monitor? We've seen some widescreen monitors won't lock up with VGA resolution due to the aspect ratio. You might try using the wvga_800x480 setting instead (that is the resolution that the vision framework uses). I am in the process of building an lX45 image as well.

-Mike

Matt,

Are you sure you have an LX-45 based FPGA? The LX-45 does not bond out 8 pins that the LX-16 does. These include pins F12, E12, D12, C12, F11, E11, E7, and E8 (this should be documented in the specification). All of this signals are routed to the edge connector signals that are used by the DVI interface on the Industrial I/O board. Because of this, MityDSP-L138F modules having the LX45 cannot use the DVI on the Industrial I/O boards. The LCD interface can be used, but not the DVI interface.

If you need the DVI interface, you need a module with an LX-16 on it.

-Mike

Hi Mike,

I didn't realize that the DVI wouldn't work with the LX-45, luckly we don't need the DVI interface. For reference are the 8 pins missing for DVI the only pin difference between LX16 and LX45?

Thanks,

Matt

See Table 1 in the datasheet. The pins are tagged with an asterix and a note at the bottom of the table. But yes, those are the 8 pins.

-Mike