ARM9 Based QNX Platforms: Software Developmenthttp://support.criticallink.com/redmine/http://support.criticallink.com/redmine/redmine/favicon.ico?16338348402012-12-04T07:43:15ZCritical Link Support
Redmine Software Development: RE: Linux DaVinci Video Port Interface (VPIF)http://support.criticallink.com/redmine/boards/13/topics/2130?r=2133#message-21332012-12-04T07:43:15ZMichael Williamson
<p>Hello,</p>
<p>This post should probably go over in the standard <a href="http://support.criticallink.com/redmine/projects/arm9-platforms/boards/10" class="external">ARM-9 Modules Software Forum</a></p>
<p>This project is really intended to support folks using the QNX port for the MityDSP-L138 or MityARM-1808 platforms.</p>
<p>As for your question:</p>
<p>We haven't used the linux V4L2 stack here with the OMAP-L138 processor SOMS yet, so I'm not sure how much help we can provide. It sounds like perhaps the VPIF output is not getting frame update events from your test code or the output DMA FIFO may be stalling. You might try to post to the TI E2E site as this is more of a processor specific question as opposed to a module issue.</p>
<p>-Mike</p> Software Development: Linux DaVinci Video Port Interface (VPIF)http://support.criticallink.com/redmine/boards/13/topics/21302012-12-03T22:01:22ZTerrence Lawrencetlawrence@mteq.com
<p>I need to setup a VPIF interface (ala V4L2) using a Mity OMAP-L138F SoM platform running DaVinci Linux to support, BT.656, 8-bit, 720x480, composite (CBVS) video output only.</p>
<p>I have attempted to make customizations to the Linux kernel code in the board configuration module, board-mityomal138.c. Which derives from board-da850.c. I added software changes to perform the pin mux setup of the VPIF display pins, register the VPIF chip, the VPIF display device interface, and the video encoder chip.</p>
<p>Thus far, using TI’s ‘vpif_test_display’ application, and the V4L2 video stack. I have been able to successfully display color bars directly from the ADV7391 video encoder, to a analog display that’s connected to the SoM’s custom baseboard.</p>
<p>However, if I try to display a frame from memory using a known Y/C pattern. I get a blank screen. Connecting a scope to a few of the VPIF’s pins, such as CLKOUT2, DOUT7, and DOUT3. We were able to verify that the VPIF’s CLKOUT2 pin is putting out a 27 MHz clock. But pins DOUT3 and DOUT7 are flat lined at about 0V.</p> Software Development: RE: DSP/BIOS dsplink for QNXhttp://support.criticallink.com/redmine/boards/13/topics/2056?r=2057#message-20572012-11-06T09:14:04ZJohn Pruitt
<p>Mark,</p>
<p>Unfortunately, we have not put together a DSPlink example running under QNX. Examples have been done under Linux so there is no problem in terms of the hardware supporting DSPlink.</p> Software Development: DSP/BIOS dsplink for QNXhttp://support.criticallink.com/redmine/boards/13/topics/20562012-11-06T08:57:40ZMark Lyonmlyon@draper.com
<p>Has anyone gotten DSPlink running under QNX for the MityDSP? I see that you have set the DSPlink memory base address in the BSP and that you have the include files for dsplink160, but I'm not sure if you've taken it beyond that.</p> Software Development: RE: NAND Flash Driver Crasheshttp://support.criticallink.com/redmine/boards/13/topics/2024?r=2042#message-20422012-10-31T11:15:55ZMark Lyonmlyon@draper.com
<p>FPGA was the problem, it works now. Thanks Mike.</p> Software Development: RE: NAND Flash Driver Crasheshttp://support.criticallink.com/redmine/boards/13/topics/2024?r=2040#message-20402012-10-31T07:47:58ZMichael Williamson
<p>Hi Mark,</p>
<p>Do you have an FPGA programmed while you are trying to perform these operations?</p>
<p>If you do, can you confirm that the FPGA configuration options <strong>float</strong> any unused IO pins? By default, FPGA bitstreams pull unused pins to ground, which can really cause problems on the EMIFA bus.</p>
<p>-Mike</p> Software Development: RE: NAND Flash Driver Crasheshttp://support.criticallink.com/redmine/boards/13/topics/2024?r=2031#message-20312012-10-30T09:46:26ZMark Lyonmlyon@draper.com
<p>No joy. When I try to erase (or just load) it, I get a whole bunch of BADBLK errors:<br />fs-etfs-mitydsp-omapl1xx: readtrans3 BADBLK on cluster <em>xxxxxx</em>, status: 30, status2: 30<br />fs-etfs-mitydsp-omapl1xx: Unable to initialise ETFS systems (Input/output error)</p>
<p>With <strong>width=2</strong> I get the following message:<br />Starting etfs driver...<br />ancr: 0x8144119, nandfcr: 0x4<br />nand id: 0x2c:ca:80:d5</p>
<p><code>#</code> ls /fs/etfs<br />.badblks .counts .filetable .reserved<br /><code>#</code> cp /fs/etfs/.counts /fs/etfs/foo<br />cp: Can't open destination file. (/fs/etfs/foo): No such process<br />cp: close (/fs/etfs/.counts): Bad file descriptor<br /><code>#</code> ls /fs/etfs <br />ls: No such file or directory (/fs/etfs)</p> Software Development: RE: NAND Flash Driver Crasheshttp://support.criticallink.com/redmine/boards/13/topics/2024?r=2030#message-20302012-10-29T15:25:36ZJohn Pruitt
<p>If the part has changed to be x8 instead of x16, then the driver command may need to change to reflect the part. I would start with</p>
<pre>
fs-etfs-mitydsp-omapl1xx -D addr=0x62000000,cs=3,width=1 -m /fs/etfs
</pre>
<p>changing the width to 1 instead of 2</p> Software Development: RE: NAND Flash Driver Crasheshttp://support.criticallink.com/redmine/boards/13/topics/2024?r=2029#message-20292012-10-29T13:16:37ZMichael Williamson
<p>Hi Mark,</p>
<p>I am wondering if you now have a module that contains a x8 NAND instead of a x16 NAND part.</p>
<p>A while ago Micron obsoleted the x16 NAND device and we are only able to get x8 NAND that the OMAP-L138 has hardware ECC capabilities for (the OMAP-L138 only supports 1-bit ECC for x16 width NAND, and the new x16 parts require a minimum of 4-bit ECC). This is posted in the MityDSP-L138 Errata, and we've update the u-Boot code and the Linux base code to detect the part installed and adjust the EMIFA drivers accordingly.</p>
<p>I am not certain if the QNX driver has this patch. I believe QNX was originally tested with earlier revisions of the OMAP-L138. I'll try to chase this down here and follow up.</p>
<p>-Mike</p> Software Development: NAND Flash Driver Crasheshttp://support.criticallink.com/redmine/boards/13/topics/20242012-10-29T10:47:21ZMark Lyonmlyon@draper.com
<p>When I try to use the NAND Flash Driver on Qnx with the default settings:<br /> fs-etfs-mitydsp-omapl1xx -D addr=0x62000000,cs=3,width=2 -m /fs/etfs<br />It appears to crash after the initial use. I can do an ls of /fs/etfs and see files there, but then it goes away. All attempts to write to it fail. I ran the erase first, but it doesn't seem to make a difference.<br />There are no messages to the console or log about the failure.</p> Software Development: RE: Linux ethernet usb supporthttp://support.criticallink.com/redmine/boards/13/topics/1977?r=1979#message-19792012-10-22T17:40:13ZJohn Pruitt
<p>This should probably be entered in the "Arm9 Based Platforms" forum instead of the "Arm9 Based QNX Platforms" since you are interested in Linux and not QNX.</p> Software Development: Linux ethernet usb supporthttp://support.criticallink.com/redmine/boards/13/topics/19772012-10-22T15:34:14ZKrishna Vallabhanenikrishna.vallabhaneni@gd-ais.com
<p>I am attemting to generate usb gadgets for Ethernet over USB.<br />Followed the instructions in the attached document.<br />There are no options for USB Gadget Support. There are needed as per document<br />LinuxDavinci version is fce1b66.<br />Using Mitydsp L138F platform.</p> Software Development: RE: Mounting SD Card under QNXhttp://support.criticallink.com/redmine/boards/13/topics/1543?r=1578#message-15782012-07-13T18:05:33ZJohn Pruitt
<p>The link you specify talks about how to enable the interface. Can you include a copy of the U-Boot session to show what commands you are entering when you try to mount the SD Card? The replies would also be useful.</p>
<p>Thanks.</p> Software Development: RE: Migrating Source Code from QNX to Linuxhttp://support.criticallink.com/redmine/boards/13/topics/1541?r=1577#message-15772012-07-13T18:02:57ZJohn Pruitt
<p>In u-boot, can you ping the server?</p>
<pre>
U-Boot > ping 10.0.0.85
</pre>
<p>Another possibility is that the specified search paths for the tftp server do not include the directory that contains the specified file.</p> Software Development: Mounting SD Card under QNXhttp://support.criticallink.com/redmine/boards/13/topics/15432012-06-29T06:34:08ZYannick BERGMANNybergmann@ndcinfrared.be
<p>Hi,</p>
<p>On the MityDSP-L138 development kit, I try to mount a SD Card.<br />I followed the procedure (<a class="external" href="http://support.criticallink.com/redmine/projects/arm9-platforms/wiki/MMC_configuration">http://support.criticallink.com/redmine/projects/arm9-platforms/wiki/MMC_configuration</a>) but are still not able to mount it.</p>
<p>Can anyone help me?</p>
<p>Thanks,</p>
<p>Yannick</p> Software Development: Migrating Source Code from QNX to Linuxhttp://support.criticallink.com/redmine/boards/13/topics/15412012-06-27T10:41:32ZAngela Newmananewman@criticallink.com
<p>I come back to you because I have another problem.<br />I read the documentation on you web site (on <a class="external" href="http://support.criticallink.com/redmine/">http://support.criticallink.com/redmine/</a>) . I understood almost everything and was able to wrote some code in Eclipse under the VirtualBox VM. I was also able to upload and run small and easy programs on the development kit.</p>
<p>After that kind of easy tests (needed of course to understand and master the MityDSP device), I intended to migrate and cross-compile some of our existing source code from QNX (OS we use for more than 15 years) to LINUX … it is not that easy because under QNX we use IPC very much and IPC seems very different between QNX and LINUX. So migration of our source code is not as easy as I imagined.</p>
<p>I tried to progress by trying to install QNX on MityDSP. As mentioned in your documentation (<a class="external" href="http://support.criticallink.com/redmine/projects/arm9-qnx-platforms/wiki/Board_Support_Package">http://support.criticallink.com/redmine/projects/arm9-qnx-platforms/wiki/Board_Support_Package</a>) , I followed all the steps but was not able to upload the QNX image on the device. In U-Boot when I launch “run bootqnxtftp” I cannot reach my tftp server running in Momentics (see attached file).</p> Software Development: RE: Running SYS/BIOS on the ARM MityDSP-L138 modulehttp://support.criticallink.com/redmine/boards/13/topics/1221?r=1223#message-12232012-02-14T15:24:23ZAnonymous
<p>Dave,<br /> I've been over on the e2e forum for a couple weeks getting our current DSP <br />running on the OMAP137. TI has confirmed that their Network Development Package<br />does not support the 137. So I'll need to get a 138 dev board and had hoped<br />yours would have been a quick solution.</p>
<p>Thanks,<br /> John C.<br /> CiDRA</p> Software Development: RE: Running SYS/BIOS on the ARM MityDSP-L138 modulehttp://support.criticallink.com/redmine/boards/13/topics/1221?r=1222#message-12222012-02-14T15:14:19ZDave Stehlikdaves@criticallink.com
<p>This is something that we haven't done yet.</p>
<p>TI has some info on this: here are some links that may be worth exploring:</p>
<p>TI's starterware:<br /><a class="external" href="http://processors.wiki.ti.com/index.php/StarterWare">http://processors.wiki.ti.com/index.php/StarterWare</a></p>
<p>and SYSBIOS wiki:<br /><a class="external" href="http://processors.wiki.ti.com/index.php/Category:SYSBIOS">http://processors.wiki.ti.com/index.php/Category:SYSBIOS</a></p>
<p>There may be some useful information from searching TI's e2e site:<br /><a class="external" href="http://e2e.ti.com/">http://e2e.ti.com/</a></p>
<p>If someone else has additional info please feel free to post it.</p>
<p>Dave</p> Software Development: Running SYS/BIOS on the ARM MityDSP-L138 modulehttp://support.criticallink.com/redmine/boards/13/topics/12212012-02-14T11:21:25ZAnonymous
<p>Hi,</p>
<pre><code>I'm currently using a Spectrum Digital's OMAP-L137 eval board to run some older DSP code and I'd like to have the ARM collect Ethernet <br />data via TI's NDK and pass it through to the DSP. Because there seems to be no underlying drivers for TI's NDK on a OMAPL137 were looking<br />for alternatives. We have a MityDSP-L138 development board and was wondering if anyone had run SYS/BIOS on the ARM side of the 138 as <br />there seems to be support for TI's NDK on the 138. Mity normally runs Linux on the ARM, but we've been using Code Composer V5.1 with <br />JTAG to debug and was hoping to keep the same development environment.</code></pre>
<pre><code>From the descriptions on the website the Mity supports SYS/BIOS and JTAG, but is this only on the DSP side?</code></pre>
<p>Any help/suggestions would be appreciated.</p>
<p>Thanks,</p>
<pre><code>John C.</code></pre> Software Development: RE: SPI clock polarityhttp://support.criticallink.com/redmine/boards/13/topics/1089?r=1090#message-10902011-12-20T12:11:43ZJohn Pruitt
<p>It looks like the spi driver does not do anything with the SPI_MODE_CKPOL_HIGH flag you are trying to use.</p>
<p>I haven't tried this with an actual device, but this is my guess on how to fix this. In the file named:</p>
<p>bsp-mitydsp-omap-l138-src/src/hardware/spi/dm644x/config.c</p>
<p>around line 50, the code looks like:</p>
<pre>
*pfmt |= DM6446_SPIFMT_PRESCALE(prescale);
if (cfg->mode & SPI_MODE_CKPHASE_HALF)
*pfmt |= DM6446_SPIFMT_PHASE1;
if (!(cfg->mode & SPI_MODE_BODER_MSB))
*pfmt |= DM6446_SPIFMT_SHIFTLSB;
</pre>
<p>Change this code to:</p>
<pre>
*pfmt |= DM6446_SPIFMT_PRESCALE(prescale);
if (cfg->mode & SPI_MODE_CKPHASE_HALF)
*pfmt |= DM6446_SPIFMT_PHASE1;
if (cfg->mode & SPI_MODE_CSPOL_HIGH)
*pfmt |= DM6446_SPIFMT_POLARITY1;
if (!(cfg->mode & SPI_MODE_BODER_MSB))
*pfmt |= DM6446_SPIFMT_SHIFTLSB;
</pre>
<p>Hope this helps.</p> Software Development: SPI clock polarityhttp://support.criticallink.com/redmine/boards/13/topics/10892011-12-20T12:09:37ZJohn Pruitt
<p>Question received outside of Redmine:</p>
<p>I am trying to interface a SPI device to the MightDSP board. The clock requirement for this device is that the clock polarity should be high, that is normally high when not being asserted. I have tried to get the clock polarity to change by doing the following:</p>
<pre>
devinfo.cfg.mode |= SPI_MODE_CSHOLD_HIGH | SPI_MODE_CKPHASE_HALF | SPI_MODE_CKPOL_HIGH;
retval = spi_setcfg(spi_handle, device, &devinfo.cfg);
</pre>
<p>The clock polarity does not change no matter whether SPI_MODE_CKPOL_HIGH is used or not. I checked the devinfo structure and the bit is being set and cleared.</p>
<p>Thanks for the help.</p> Software Development: RE: OMAP I2Chttp://support.criticallink.com/redmine/boards/13/topics/521?r=1007#message-10072011-11-15T15:30:18ZMark Lyonmlyon@draper.com
<p>Yes, it works (thanks):<br /><pre>
# ./i2c-test_g
I2C driver demonstration program
ret = 0, address: 0x50, offset: 0x8
Data: 00 50 c2 bf 8e 09
#
</pre></p>
<p>I did not notice that i2c_get sends the offset - my bad.<br />I know that there are a bunch of addresses, and was actually testing with 0x38, so we were trying the same thing in that regard.</p> Software Development: RE: OMAP I2Chttp://support.criticallink.com/redmine/boards/13/topics/521?r=1006#message-10062011-11-15T15:24:02ZJohn Pruitt
<p>Mark,</p>
<p>I probably should have used O_RDWR instead of O_RDONLY. I am surprised it worked with just O_RDONLY.</p>
<p>The SENDRECV is important, at least for my device. I am reading a device register and the protocol is that I need to send the offset to the device and then read the number of bytes I am interested in.</p>
<p>I did not try it without the stop.</p>
<p>I made up my own program so I guess I was not influenced by the qnx sample.</p>
<p>Can you run this program on your board and see activity?</p>
<p>I have also learned that the memory device I was accessing actually responds to a set of addresses (0x50,0x51...). It is important to make sure that your device has a unique address.</p>
<p>John</p> Software Development: RE: OMAP I2Chttp://support.criticallink.com/redmine/boards/13/topics/521?r=1005#message-10052011-11-15T15:17:57ZMark Lyonmlyon@draper.com
<p>Interesting. We were using Qnx's demo which uses DCMD_I2C_RECV rather than DCMD_I2C_SENDRECV so that was part of the solution. <br />It is also calling open with O_RDWR rather than O_RDONLY - not sure if that is a problem.<br />Also the call to DCMD_I2C_SET_BUS_SPEED seems to mess the works up, and we’ll need to look further at that, but I’m ok with default speeds for now.<br />Finally, the Qnx demo was setting dev_data.header.stop to 0 rather than 1. I'll look at these differences individually when I get a chance.</p>
<p>Thanks,</p>
<p>mark</p> Software Development: RE: OMAP I2Chttp://support.criticallink.com/redmine/boards/13/topics/521?r=1004#message-10042011-11-15T13:27:00ZJohn Pruitt
<p>I am attaching a test program that was used on a board to read the factory config information using i2c0.</p>
<p>The output of the i2c_get program is:</p>
<pre>
# i2c_get -i 0 0x50 8 6
i2c0: 0x50: 0x8: 00 50 c2 bf 89 2a
#
</pre>
<p>This reads 6 bytes from offset 8 from the device at address 0x50. These 6 bytes are the mac address for the device.</p>
<pre>
# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
inet 127.0.0.1 netmask 0xff000000
emac0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:50:c2:bf:89:2a
media: Ethernet none (100baseTX full-duplex)
status: active
inet 10.0.25.167 netmask 0xffff0000 broadcast 10.0.255.255
#
</pre>
<p>The output from the test program is:</p>
<pre>
I2C driver demonstration program
ret = 0, address: 0x50, offset: 0x8
Data: 00 50 c2 bf 89 2a
</pre>
<p>Sometimes, when switching between the i2c_get and the test program, the test program would get an I/O error. I don't know for sure but I suspect the i2c_get program did not properly clean things up. Running the test program again would then start working.</p>
<p>I think this program demonstrates that the i2c-dm6446 driver is working ok on the indio board, at least for one device.</p>
<p>Now the question becomes, what is different between the device you are trying to talk to and the on-module memory device that I was using.</p>
<p>You should be able to run this program on your board.</p> Software Development: RE: OMAP I2Chttp://support.criticallink.com/redmine/boards/13/topics/521?r=999#message-9992011-11-14T17:13:52ZJohn Pruitt
<p>Can you try to get the sample program that the qnx engineer used?</p>
<p>Thanks.</p> Software Development: RE: OMAP I2Chttp://support.criticallink.com/redmine/boards/13/topics/521?r=998#message-9982011-11-14T09:47:38ZMark Lyonmlyon@draper.com
<p>An engineer from QNX hooked a scope to I2C0 lines on their EVM board and sent the sendrecv command. They were able to get a signal on the lines, proving that their driver works with the utilities. They said this indicated that the BSP was causing the issue.</p> Software Development: RE: OMAP I2Chttp://support.criticallink.com/redmine/boards/13/topics/521?r=997#message-9972011-11-11T15:04:08ZJohn Pruitt
<p>IFor what it is worth, it should be noted that the i2c accesses in the startup code and in the i2c_get utility are done without interrupts. The i2c resource manager is probably using interrupts. It is possible that something needs to be set to enable the i2c interrupts. Although, this probably would not explain the absence of activity that you are observing on the lines.</p> Software Development: RE: FPGA Driverhttp://support.criticallink.com/redmine/boards/13/topics/255?r=973#message-9732011-11-03T14:08:18ZJohn Pruitt
<p>I have posted a new BSP which has a fixed FPGA driver and fix to the timer routines so the clock period can be changed via ClockPeriod().</p>
<p>Please see <a class="external" href="http://support.criticallink.com/redmine/attachments/download/840/qnxbsp-20111103.zip">http://support.criticallink.com/redmine/attachments/download/840/qnxbsp-20111103.zip</a> under the files tab.</p> Software Development: RE: OMAP I2Chttp://support.criticallink.com/redmine/boards/13/topics/521?r=966#message-9662011-11-01T09:12:14ZJohn Pruitt
<p>Mark,</p>
<p>I2C0 is not something that needs to be turned on. It is used internally in the startup code to read configuration information on the L138 module, so if you are booting into QNX, then i2c0 has been used.</p>
<p>QNX provided i2c drivers but I am not sure how to use them. We have supplied two commands (i2c_get and i2c_set) to help with manually accessing device registers via i2c. If you just need occasional access or just to make changes at initialization, the commands may be sufficient. If you need to transfer lots of data, then you probably want something else.</p>
<p>The source to the utilities is available at src/utils/i/i2c_get and src/utils/i/i2c_set.</p>
<p>Hope this helps.</p>
<p>John</p> Software Development: RE: OMAP I2Chttp://support.criticallink.com/redmine/boards/13/topics/521?r=965#message-9652011-11-01T09:00:13ZMark Lyonmlyon@draper.com
<p>It looks like neither I2C driver is started by default.<br />We are trying to use I2C0<br />There is an error generated if we include the line:<br /><pre>
omapl138_psc_enable (PSC_MODULE_I2C0);
</pre><br />in init_hwinfo.c (it is not defined in omapl1xx.h)</p> Software Development: RE: FPGA Driverhttp://support.criticallink.com/redmine/boards/13/topics/255?r=959#message-9592011-10-28T14:44:43ZJohn Pruitt
<p>Mark,</p>
<p>The files under /dev/fpga are not intended to be executed. They are intended to be opened and then read from or written to. They are created by the fpga-omapl1xx resource manager. As shown in the examples on the wiki page, you can read from them (use of "cat") or you can write to them (use of "echo"). You can not execute them.</p>
<p>Hope this helps.</p> Software Development: RE: FPGA Driverhttp://support.criticallink.com/redmine/boards/13/topics/255?r=958#message-9582011-10-28T14:27:15ZMark Lyonmlyon@draper.com
<p>Tried that - now I'm having a very strange, possibly unrelated problem where the files created under /dev/fpga are created without the executable bit (e.g. 660 rather than 770). Even if I change the permissions they will not execute. No build errors, and I get the same behavior even when I roll back the change to fpga_main.c</p> Software Development: RE: FPGA Driverhttp://support.criticallink.com/redmine/boards/13/topics/255?r=949#message-9492011-10-27T17:04:29ZJohn Pruitt
<p>Mark,</p>
<p>These is a mistake in the fpga driver as provided. It is printing out the virtual addresses for the cores in the fpga instead of the physical addresses. The virtual addresses are not real useful. The example in the wiki page shows:</p>
<pre>
# cat /dev/fpga/devices
Enumerating Devices
Found Device ID 00-Base Module (01.00) at 01801000
Found Device ID 23-ADS7843 Touch Screen (01.02) at 01801080
Found Device ID 07-I2C Interface (01.00) at 01801100
Found Device ID 02-LCD Settings Controller (01.00) at 01801180
Found Device ID 01-TFP410 DVI Controller (01.00) at 01801200
</pre>
<p>where the 01801000 address is actually a virtual address. A better output is:</p>
<pre>
# cat /dev/fpga/devices
Enumerating Devices
Found Device ID 00-Base Module (01.00) at 66000000
Found Device ID 23-ADS7843 Touch Screen (01.02) at 66000080
Found Device ID 07-I2C Interface (01.00) at 66000100
Found Device ID 02-LCD Settings Controller (01.00) at 66000180
Found Device ID 01-TFP410 DVI Controller (01.00) at 66000200
#
</pre>
<p>which shows the addresses in the 0x66000000 address range.</p>
<p>I have attached a changed file for the fpga driver that causes the above addresses to be shown instead of the virtual addresses.</p> Software Development: RE: FPGA Driverhttp://support.criticallink.com/redmine/boards/13/topics/255?r=943#message-9432011-10-27T15:35:39ZMark Lyonmlyon@draper.com
<p>Understood. I have a memory block in the FPGA that I was able to examine using mmap_device_memory().<br />The offset was a reference to the startup script:<br />@
#######################################################################
## FPGA - start the fpga driver
#######################################################################<br /> echo Starting the fpga driver<br /> fpga-omapl1xx -b 0x01e26000 -f 0x66000000 &<br />@</p> Software Development: RE: FPGA Driverhttp://support.criticallink.com/redmine/boards/13/topics/255?r=942#message-9422011-10-27T15:29:14ZJohn Pruitt
<p>Mark,</p>
<p>The 5 fpga device files (cmd, image, state, version, and devices) are for loading an image into the fpga and getting information about that loaded image. Think of them as fpga administrative tools.</p>
<p>I think what you are asking is how to actually use the cores that are loaded as part of the image. That all depends on what the cores are doing. In general, you will probably need a QNX driver (i.e. resource manager) to work with the interface provided by the core. If the core provides a standard interface, then you may be able to use an existing QNX resource manager and just specify the starting address of the interface registers. If there is not an existing QNX resource manager, then you will need to write one of your own. The QNX documentation talks about how to do this and there are several examples in the BSP. The gpio driver is one, the fpga drivers is another, the source for the serial driver is another.</p>
<p>What do you mean that the FPGA is mapped into 0x66000000? Is this the starting address of your interface registers?</p>
<p>Thanks.</p> Software Development: RE: FPGA Driverhttp://support.criticallink.com/redmine/boards/13/topics/255?r=941#message-9412011-10-27T14:51:27ZMark Lyonmlyon@draper.com
<p>I have the FPGA driver loaded, with the FPGA mapped into 0x66000000.<br />If I want to access the FPGA for a user application how do I map it in? Just use the h/w address? The FPGA devices seem specific to the 5 commands you've created. Should I create a new FPGA or EMIFA device that I can open and interface to, or is there some other method you'd recommend?</p> Software Development: RE: Pin MUXhttp://support.criticallink.com/redmine/boards/13/topics/879?r=934#message-9342011-10-26T15:57:39ZMark Lyonmlyon@draper.com
<p>Just saw a signal out of the port - thanks. It may have been a conflict with the I2C or something else we tried along the way that broke it. Either way this was a big help - thanks.</p> Software Development: RE: Pin MUXhttp://support.criticallink.com/redmine/boards/13/topics/879?r=931#message-9312011-10-26T15:19:10ZJohn Pruitt
<p>Mark,</p>
<p>I have tried using a scope on an INDIO board (80-000268RI-2 rev. B, serial number 110765) with a module (L138-FG-225-RC, serial #110441) and have the following results.</p>
<p>What I did:</p>
<ul>
<li>Started a new workspace</li>
<li>Imported the qnxbsp-20110629.zip bsp</li>
<li>Loaded the pinmux_indio.pin file into the pin setup program.</li>
<li>Added UART2. Turned off the i2c1 pins that collided with TX and RX.</li>
<li>Saved the settings into the pinmux_indio.pin file</li>
<li>Saved the settings into the pinmux_indio.h file</li>
<li>Modified the init_hwinfo.c to include a <code>omapl138_psc_enable (PSC_MODULE_UART2);</code> line in the omapl138_psc_init() function.</li>
<li>Modified the bsp-mitydsp-omap-l138.bsh file to uncomment the lines<br /><pre>
devc-ser8250 -u4 -M -e -F -S -b115200 -c150000000/16 0x01d0d000^2,61
waitfor /dev/ser4
</pre></li>
<li>Modified the bsp-mitydsp-omap-l138.bsh file to comment out the lines<br /><pre>
#display_msg Starting I2C1 Services
#i2c-dm6446 -a0x2 -i51 -p0x01e28000 -f24000000 -l0x1000 --u1
#waitfor /dev/i2c1 10
</pre></li>
<li>Use File->Save All to save all the changed files</li>
<li>Build the bsp-mitydsp-omap-l138 project</li>
<li>Open the System Builder perspective to start the tftp server</li>
<li>Open a terminal view, connect to the board on serial port 1</li>
<li>Turn on the board, stop at a u-boot prompt</li>
<li>Type dhcp to get an ip address</li>
<li>Type run bootqnxtftp to download and boot the qnx image</li>
<li>At the qnx prompt, verify that /dev/ser4 exists</li>
<li>Type <code>ls -l /proc/boot >/dev/ser4</code></li>
<li>Attach the ground of the scope probe to <code>TP1</code> which is on the edge of the board close to the "l" in Critical</li>
<li>Put the scope probe on pin 6 of the Expansion port connector. Pin 6 is the pin closest to the TP1. Also closest to the letter "E" of Expansion Port.
<ul>
<li>TX is on pin 6, RX is on pin 2</li>
<li>TX_ENB is on pin 1</li>
</ul>
</li>
<li>When nothing is going on, the probe seems to show a level of about 3.3 volts.</li>
<li>When the <code>ls</code> command is repeated, there is a flurry of activity on the scope as the characters are being output.</li>
</ul>
<p>As an additional test, tried setting up access to the TX_ENB via the GPIO bank 0 pin 9. This involved the following steps (with a couple of mistakes along the way)</p>
<ul>
<li>Execute <code>gpio-omapl1xx -p out=gp0p9@tx_enb:1 &</code> to start the gpio driver and create a /dev/tx_enb device file.</li>
<li>cat /dev/tx_enb to see that the current value is 0</li>
<li>Put the probe on line 1 and see that the level is 0</li>
<li><code>echo 1 >/dev/tx_enb</code> to set the level to 1</li>
<li>Nothing happened on the scope line</li>
<li>I realized I had not turned on the pinmux for gp0 pin 9.</li>
<li>Changed the pinmux, saved the .pin and .h files</li>
<li>Rebuilt the qnx image</li>
<li>Rebooted the board</li>
<li>Tried again, same result. </li>
<li>Noticed that the initial value for tx_enb should have been 1, not 0.</li>
<li>Realized that just changing the pinmux_indio.h file may not cause a rebuild. </li>
<li>Did a project clean</li>
<li>Rebuilt the project</li>
<li>Rebooted the board</li>
<li>Tried again, now it works. The scope on line 1 tracks the state of /dev/tx_enb.</li>
</ul>
<p>If you haven't done a clean and a rebuild, please do so. Momentics is nice in a lot of ways but catching dependencies and the need to rebuild is not one of them.</p>
<p>Please let me know how your steps are different from these.</p>
<p>Hope this helps.</p>
<p>John</p> Software Development: RE: Pin MUXhttp://support.criticallink.com/redmine/boards/13/topics/879?r=929#message-9292011-10-26T07:45:34ZMark Lyonmlyon@draper.com
<p>We are using RS-232 at TTL levels, so that is not a problem.<br />We had done all the steps you outlined and we are not seeing output from the pins using an scope.</p> Software Development: RE: Pin MUXhttp://support.criticallink.com/redmine/boards/13/topics/879?r=924#message-9242011-10-25T16:32:13ZJohn Pruitt
<p>Mark,</p>
<p>I do not know of any qnx code that has been used with this port. I have been talking with the hardware guys and it seems that this port is an expansion port. This means there needs to be additional hardware added depending on what kind of output you intend to use. For example, if you want RS-232, the signal levels are TTL so something needs to be done to change the levels to something appropriate for RS-232. (I am a software guy so if this explanation does not make sense, please forgive me.) There also needs to be something done if 485 signals are needed.</p>
<p>There have been different revisions of this port. We used to have an isolation circuit on the board that also produced 485 levels but now, the signals come directly to the J504 port. This means you can run the lines to something that will produce RS-232 level signals, or you can run the lines to something that will produce the 485 signals.</p>
<p>What is your intended usage for the port? RS-232 or RS-485?</p>
<p>Assuming RS-232, the items that need to be taken care of in order to use the port are:</p>
<ul>
<li>Run a ribbon cable to some hardware that will change the signal levels to RS-232.</li>
<li>Change the pinmux to include the UART2 RX and TX lines. It looks like your file does this.</li>
<li>Change the bsp-mitydsp-omap-l138.bsh file to enable Uart2. It looks like you have done this.</li>
<li>Change the omapl138_psc_init() function in init_hwinfo.c so that the first few lines look like:<br /><pre><code class="ruby syntaxhl"><span class="n">void</span> <span class="n">omapl138_psc_init</span><span class="p">(</span><span class="n">void</span><span class="p">)</span>
<span class="p">{</span>
<span class="sr">//</span> <span class="no">Enable</span> <span class="n">the</span> <span class="n">resources</span> <span class="n">we</span> <span class="n">need</span> <span class="o">-</span> <span class="n">can</span> <span class="n">disable</span> <span class="n">unused</span> <span class="n">things</span> <span class="n">here</span> <span class="n">to</span> <span class="n">save</span> <span class="n">power</span>
<span class="n">omapl138_psc_enable</span> <span class="p">(</span><span class="no">PSC_MODULE_EMIFA</span><span class="p">);</span>
<span class="n">omapl138_psc_enable</span> <span class="p">(</span><span class="no">PSC_MODULE_UART1</span><span class="p">);</span>
<span class="n">omapl138_psc_enable</span> <span class="p">(</span><span class="no">PSC_MODULE_UART0</span><span class="p">);</span>
<span class="n">omapl138_psc_enable</span> <span class="p">(</span><span class="no">PSC_MODULE_UART2</span><span class="p">);</span> <span class="sr">//</span> <span class="no">This</span> <span class="n">is</span> <span class="n">the</span> <span class="n">new</span> <span class="n">line</span>
<span class="o">...</span>
<span class="p">}</span>
</code></pre>
<ul>
<li>Please double check that this has been done.</li>
</ul></li>
</ul>
<p>You should not need the transmit enable line (GP0<sup><a href="#fn9">9</a></sup>) in order to use RS-232 output. I think I had fat fingers yesterday. The GP0<sup><a href="#fn8">8</a></sup> should have been GP0<sup><a href="#fn9">9</a></sup>. This is the transmit enable for the port. Sorry for the mistake.</p>
<p>If the intended usage is 485, then GP0<sup><a href="#fn9">9</a></sup> will also need to be added to the pinmux and a way of driving the pin when needed would have to be added.</p>
<p>Sorry for the confusion, hope this helps.</p>
<p>John</p> Software Development: RE: ClockPeriodhttp://support.criticallink.com/redmine/boards/13/topics/842?r=910#message-9102011-10-24T16:26:56ZRob Gillisrobg@jwfishers.com
<p>John,</p>
<p>The timer_load callout only gets called when you change the system tick period, so it will only be indeterminate (and expected to behave that way) for a single tick. And with either fix you need to reset the timer count otherwise you will have problems when going from a larger tick period to a smaller tick period.</p>
<p>Thanks,<br />Rob</p> Software Development: RE: ClockPeriodhttp://support.criticallink.com/redmine/boards/13/topics/842?r=908#message-9082011-10-24T15:55:33ZJohn Pruitt
<p>Rob,</p>
<p>I think the method I described was a way of giving the timer control over the reload so it could be done gracefully.</p>
<p>Your method sounds like it would be fine for a situation where you have some setup changes to do and don't really care if the timer interrupts are a little bit off. I think that by stopping the timer, doing a reload, and then restarting, there will be a time between interrupts that is indeterminate. Using the other method probably keeps these times to either the old counter value or the new one. Not sure what advantage this is, but it might matter in other situations. After the setup period, everything should be fine.</p>
<p>I am not sure when the next BSP release will be, but these changes will be included.</p>
<p>Glad we found the right area for you.</p>
<p>John</p> Software Development: RE: ClockPeriodhttp://support.criticallink.com/redmine/boards/13/topics/842?r=907#message-9072011-10-24T15:44:17ZRob Gillisrobg@jwfishers.com
<p>Hi John,</p>
<p>I need to do more testing, but it looks like I have a fix. You cannot change the timer's period while it is running, so I modified the timer_load callout to stop the timer first and zero the counter before changing the period:</p>
<p>In omapl1xx.h:<br />#define OMAPL1xx_TCR_ENA12_OFF (0xFFFFFF3F)</p>
<p>In callout_timer_omapl1xx.S:<br />CALLOUT_START(timer_load_omapl1xx, 0, patch_timer)<br /> /*
* Get the address of the timer registers (patched)<br /> */<br /> mov ip, #0x000000ff<br /> orr ip, ip, #0x0000ff00<br /> orr ip, ip, #0x00ff0000<br /> orr ip, ip, #0xff000000</p>
<pre><code>/*
* stop the timer<br /> */<br /> ldr r0, [ip, #OMAPL1xx_TMR_TCR]<br /> and r0, r0, #OMAPL1xx_TCR_ENA12_OFF<br /> str r0, [ip, #OMAPL1xx_TMR_TCR]</code></pre>
<pre><code>/*
* reset the timer count<br /> */<br /> mov r0, #0x00000000<br /> str r0, [ip, #OMAPL1xx_TMR_TIM12]</code></pre>
<pre><code>/*
* Get the load value <br /> */<br /> ldr r0, [r1, #QT_TIMER_LOAD]</code></pre>
<pre><code>/*
* load counter value<br /> */<br /> str r0, [ip, #OMAPL1xx_TMR_PRD12]</code></pre>
<pre><code>/*
* start the timer running<br /> */<br /> ldr r0, [ip, #OMAPL1xx_TMR_TCR]<br /> orr r0, r0, #OMAPL1xx_TCR_ENA12<br /> str r0, [ip, #OMAPL1xx_TMR_TCR]</code></pre>
<pre><code>mov pc, lr<br />CALLOUT_END(timer_load_omapl1xx)</code></pre>
<p>Thanks for your help with this problem. I didn't get to try your solution, it may also have worked. Could you please test out this fix when you have a setup you can use, and incorporate the fix into the next BSP release?</p>
<p>Thanks,<br />Rob</p> Software Development: RE: Pin MUXhttp://support.criticallink.com/redmine/boards/13/topics/879?r=906#message-9062011-10-24T15:25:28ZMark Lyonmlyon@draper.com
<p>We were able to toggle other GPIO lines that come out the connectors on the back, but unable to see any activity with GP0<sup><a href="#fn8">8</a></sup>, nor GP1<sup><a href="#fn2">2</a></sup> or GP1<sup><a href="#fn3">3</a></sup>, or in fact any pin on J504.<br />We are using a scope to look at the pins.<br />I've tried all the various combinations of disabling UART2 and enabling the GPIO pins.<br />It appears that the industrial IO board / dev kit wire the SOM directly to J504 - what, if anything is between the L138 and the edge connector on the SOM?<br />I've also tried Linux and I'm unable to get the port working there.<br />Do you have any code sample that outputs to the port?</p> Software Development: RE: Pin MUXhttp://support.criticallink.com/redmine/boards/13/topics/879?r=903#message-9032011-10-24T11:32:38ZJohn Pruitt
<p>Mark,</p>
<p>I did not understand the details of uart 2 on our kit before. As I understand it now, it is connected as a half-duplex RS-485 interface. If you are expecting to see rs-232 serial port activity, this is not going to work. If you are expecting RS-485 signals, then there is hope.</p>
<p>There is an additional GPIO line that serves as a transmit-enable for the half-duplex interface. This is GP0<sup><a href="#fn8">8</a></sup>. (bank 0, offset 8) I believe this line needs to be set in order to transmit anything. The regular devc-ser8250 doesn't know anything about this line.</p>
<p>In order to drive the gpio lines, you will need to change the pinmux to include gp0<sup><a href="#fn8">8</a></sup>. (use the gpio line instead of UART2_CTS) In the *.bsh file, there is a line with gpio-omapl1xx which can be used to drive gpio lines. The gpio-omapl1xx driver takes arguments of the form -p out=gp<bank>p<pin>@<name>:<value> where:</p>
<ul>
<li>bank is the gpio bank number. In this case, the bank is 0</li>
<li>pin is the pin or offset number. In this case, 8</li>
<li>name is the desired name of the "device" in /dev. If you don't use the @name, the name will be /dev/gp0p8. Or use a name of your choice.</li>
<li>value is the initial value, 0 or 1.</li>
</ul>
<p>For testing purposes, you should be able to set the gpio pin, try transmitting, and then see activity on the lines.</p>
<p>For real operation, the use of the gpio line needs to be tied to the beginning and end of transmissions. This may be easy to do within your application, or you may want a modified devc-ser8250 driver. (needs to know the line is half-duplex and has a gpio line available to enable transmit.)</p>
<p>Hope this helps.</p> Software Development: RE: Pin MUXhttp://support.criticallink.com/redmine/boards/13/topics/879?r=902#message-9022011-10-24T10:55:42ZMark Lyonmlyon@draper.com
<p>It may be more of a hardware problem - we have the industrial IO board 80-000268RI-2 serial 110759 and we see no RS-485 signal out of J504 that makes any sence. We've also tried Linux and failed to get output there too.</p> Software Development: RE: Pin MUXhttp://support.criticallink.com/redmine/boards/13/topics/879?r=901#message-9012011-10-24T10:21:10ZMark Lyonmlyon@draper.com
<p>Here is a snapshot of my last attempt (attached)</p>
<p>Devices configured:</p>
<p>EMAC (RMII)<br />EMIFA/EMIFB<br />MMC/SD1<br />UART0,1,2<br />SPI0 (SCS 0 and 1 only as 2-5 collide with UART 0)<br />SPI1 (SCS 0 and 1 only as 2-5 collide with UARTS 1&2)<br />I2C0<br />There are a few GPIO pins added to the mix, not sure what for: GP0[1,2,3,4,6,7,13,15], GP6[12,13,15]</p> Software Development: RE: Pin MUXhttp://support.criticallink.com/redmine/boards/13/topics/879?r=900#message-9002011-10-24T09:48:22ZJohn Pruitt
<p>Mark,</p>
<p>Please send you pinmux (both the .pin and the .h files) and startup script files. You can just attach them to a forum message reply using the Files and Add another file links.</p>
<p>The startup script files will need to make sure that the clock speed on both of the enabled devc-ser8250 lines have the same -c option (specifies the clock speed)</p>
<p>Do you know what revision of the indio board you are using?</p>
<p>Thanks.</p>
<p>John</p> Software Development: RE: Pin MUXhttp://support.criticallink.com/redmine/boards/13/topics/879?r=899#message-8992011-10-24T07:47:38ZMark Lyonmlyon@draper.com
<p>We aren't having any luck, John will try to call, and we've sent along the files.</p> Software Development: RE: ClockPeriodhttp://support.criticallink.com/redmine/boards/13/topics/842?r=895#message-8952011-10-20T17:22:32ZJohn Pruitt
<p>The QT_TIMER_LOAD value of 0x30 is just an offset into the system page or some structure. It is not the actual load value.</p> Software Development: RE: ClockPeriodhttp://support.criticallink.com/redmine/boards/13/topics/842?r=894#message-8942011-10-20T17:20:20ZJohn Pruitt
<p>Rob,</p>
<p>It looks like there is a callout function that does not really do what it is supposed to. I suspect the kernel is expecting the timer to change but nothing is happening at the lower level. The timer_load values you show seem consistent with a 24MHz clock.</p>
<p>The function in question is timer_reload_omapl1xx in src/hardware/startup/lib/arm/callout_timer_omapl1xx.S. The function just returns.</p>
<p>In callout_timer_pxa250.S, the timer_reload function actually does something. It looks like it is supposed to reload the #QT_TIMER_LOAD value into the timer registers, or it is just supposed to disable the timer interrupt and presumably another call to timer_load will be done with the new value.</p>
<p>On the omap, (<a class="external" href="http://www.ti.com/lit/ug/spruh77/spruh77.pdf">http://www.ti.com/lit/ug/spruh77/spruh77.pdf</a>) it looks like there is a way to do what we want but I think a couple of things need to change. I don't currently a board set up so this is just a guess.</p>
<p>Current way of doing things:</p>
timer_load_omapl1xx():
<ul>
<li>loads the QT_TIMER_LOAD value into the TMR_PRD12 register
<ul>
<li>The QT_TIMER_LOAD value is defined in src/hardware/startup/lib/arm/a.le/asmoff.def as 0x30. </li>
</ul>
</li>
<li>sets the ENA12 register to 2.
<ul>
<li>The ENA12 value of 2 says that the timer will continuously reload with PRD12 value.</li>
</ul></li>
</ul>
timer_reload_omapl1xx():
<ul>
<li>does nothing, just returns</li>
</ul>
<p>Current code:</p>
<pre>
CALLOUT_START(timer_load_omapl1xx, 0, patch_timer)
/*
* Get the address of the timer registers (patched)
*/
mov ip, #0x000000ff
orr ip, ip, #0x0000ff00
orr ip, ip, #0x00ff0000
orr ip, ip, #0xff000000
/*
* Get the load value
*/
ldr r0, [r1, #QT_TIMER_LOAD]
/*
* load counter value
*/
str r0, [ip, #OMAPL1xx_TMR_PRD12]
/*
* start the timer running
*/
ldr r0, [ip, #OMAPL1xx_TMR_TCR]
orr r0, r0, #OMAPL1xx_TCR_ENA12
str r0, [ip, #OMAPL1xx_TMR_TCR]
mov pc, lr
CALLOUT_END(timer_load_omapl1xx)
</pre><br /><pre>
CALLOUT_START(timer_reload_omapl1xx, 0, patch_timer)
/*
* Get the address of the timer registers (patched)
*/
mov ip, #0x000000ff
orr ip, ip, #0x0000ff00
orr ip, ip, #0x00ff0000
orr ip, ip, #0xff000000
mov pc, lr
CALLOUT_END(timer_reload_omapl1xx)
</pre>
<p>Possible way of fixing things:</p>
timer_load_omapl1xx():
<ul>
<li>load the QT_TIMER_LOAD value into both the TMR_PRD12 and the TMR_REL12 registers</li>
<li>set the ENA12 register to 3</li>
</ul>
timer_reload_omapl1xx():
<ul>
<li>load the QT_TIMER_LOAD value into the TMR_REL12 register.</li>
</ul>
<pre>
CALLOUT_START(timer_load_omapl1xx, 0, patch_timer)
/*
* Get the address of the timer registers (patched)
*/
mov ip, #0x000000ff
orr ip, ip, #0x0000ff00
orr ip, ip, #0x00ff0000
orr ip, ip, #0xff000000
/*
* Get the load value
*/
ldr r0, [r1, #QT_TIMER_LOAD]
/*
* load counter value
*/
str r0, [ip, #OMAPL1xx_TMR_PRD12]
str r0, [ip, #OMAPL1xx_TMR_REL12]
/*
* start the timer running
*/
ldr r0, [ip, #OMAPL1xx_TMR_TCR]
/*orr r0, r0, #OMAPL1xx_TCR_ENA12*/
orr r0, r0, #(0x3 <<6)
str r0, [ip, #OMAPL1xx_TMR_TCR]
mov pc, lr
CALLOUT_END(timer_load_omapl1xx)
</pre><br /><pre>
CALLOUT_START(timer_reload_omapl1xx, 0, patch_timer)
/*
* Get the address of the timer registers (patched)
*/
mov ip, #0x000000ff
orr ip, ip, #0x0000ff00
orr ip, ip, #0x00ff0000
orr ip, ip, #0xff000000
/*
* Get the load value
*/
ldr r0, [r1, #QT_TIMER_LOAD]
/*
* load counter value
*/
str r0, [ip, #OMAPL1xx_TMR_REL12]
mov pc, lr
CALLOUT_END(timer_reload_omapl1xx)
</pre>
<p>Can you try making these changes?</p>
<p>Thanks.</p> Software Development: RE: ClockPeriodhttp://support.criticallink.com/redmine/boards/13/topics/842?r=891#message-8912011-10-20T13:32:09ZRob Gillisrobg@jwfishers.com
<p>Hi John,</p>
<p>The pidin program does not display the info we're interested in, so I modified my clock_period program to display the timer_load value (not to be confused with the timer_load callout) from the syspage. Here are the results:</p>
<ol>
<li>./clock_period <-- 1 millisecond<br />ClockPeriod: 999999 nsecs<br />timer_load: 24000</li>
</ol>
<ol>
<li>./clock_period 2000000 <-- 2 milliseconds</li>
<li>./clock_period<br />ClockPeriod: 1999999 nsecs<br />timer_load: 48000</li>
</ol>
<ol>
<li>./clock_period 5000000 <-- 5 milliseconds</li>
<li>./clock_period<br />ClockPeriod: 4999999 nsecs<br />timer_load: 120000</li>
</ol>
<ol>
<li>./clock_period 200000 <-- 200 microseconds</li>
<li>./clock_period<br />ClockPeriod: 199999 nsecs<br />timer_load: 4800</li>
</ol>
<p>Looks like QNX is putting the correct values into the syspage. I don't know whether they are not getting loaded into the timer register (except for initial boot up), or if there is some other issue that causes sleep to malfunction.</p>
<p>Any ideas?</p>
<p>Thanks,<br />Rob</p> Software Development: RE: Pin MUXhttp://support.criticallink.com/redmine/boards/13/topics/879?r=881#message-8812011-10-20T10:06:46ZJohn Pruitt
<p>You will probably need to modify the omapl138_psc_init() to include a line like:</p>
<p>omapl138_psc_enable (PSC_MODULE_UART2);</p>
<p>Hope this helps.</p> Software Development: Pin MUXhttp://support.criticallink.com/redmine/boards/13/topics/8792011-10-20T09:27:45ZMark Lyonmlyon@draper.com
<p>We are trying to use the MityDSP L138 UART2 on the PROFIBUS dev kit with Qnx. We are connecting via J504.<br />I saw mention of removing jumper JP500-502 and installing JP503, but those do not appear to be on our board.<br />We've updated the configuration script to enable the UART and we have tried updating pinmux_indio.h using the TI PinSetup.exe application, but we still are not output from that port - what am I missing?</p>
<p>80-000395 - MityDSP Development Kit including L138-FG-225-RC MityDSP-L138F 456MHz Module with LX16 FPGA</p> Software Development: RE: ClockPeriodhttp://support.criticallink.com/redmine/boards/13/topics/842?r=872#message-8722011-10-18T14:48:12ZJohn Pruitt
<p>Rob,</p>
<p>With regards to the syspage, I was hoping to see values change after changing the ClockPeriod. Sections relating to time and clocks seemed like good candidates. If the x86 shows changes in one way and the omap shows changes in a different way, then this could help isolate the problem.</p>
<p>Right now, I am not in a position to replicate this problem. I have never tried this and have no reason to doubt that it is happening as you say.</p>
<p>Hope this helps.</p>
<p>John</p> Software Development: RE: QNX BSP Timershttp://support.criticallink.com/redmine/boards/13/topics/841?r=871#message-8712011-10-18T14:38:41ZRob Gillisrobg@jwfishers.com
<p>John,</p>
<p>We have tried using ClockCycles(). I think it may be working for us but will check with the other developers to make sure.</p>
<p>Thanks,<br />Rob</p> Software Development: RE: ClockPeriodhttp://support.criticallink.com/redmine/boards/13/topics/842?r=870#message-8702011-10-18T14:37:03ZRob Gillisrobg@jwfishers.com
<p>John,</p>
<p>I just tried the above mentioned change, and as you suspected it did not fix the problem but was worth a try.</p>
Regarding the pidin info, could you let me know what section of the syspage you would like to see. I did capture the qtime section:
<ol>
<li>pidin syspage=qtime<br />Header size=0x0000009c, Total Size=0x00000de0, #Cpu=1, Type=4<br />Section:qtime offset:0x00000190 size:0x00000060<br /> boot:38962200 CPS:00000000016e3600 rate/scale:41666666/-15 intr:21</li>
</ol>
<p>This stays constant no matter what the ClockPeriod() is set for, which is what I would expect. My x86 board has the same behavior.</p>
<p>Let me know what to try next. Also, are you able to replicate this problem at your office?</p>
<p>Thanks,<br />Rob</p> Software Development: RE: QNX BSP Timershttp://support.criticallink.com/redmine/boards/13/topics/841?r=862#message-8622011-10-17T10:06:46ZJohn Pruitt
<p>Rob,</p>
<p>Have you tried using ClockCycles()?</p>
<p>John</p> Software Development: RE: ClockPeriodhttp://support.criticallink.com/redmine/boards/13/topics/842?r=861#message-8612011-10-17T10:02:35ZJohn Pruitt
<p>Rob,</p>
<p>I see your point.</p>
<p>We have not provided the arm clock handling routines so in that sense, this would seem to be the arm-specific part of QNX. My understanding though, is that the kernel gets things like device specific handling routines from the bsp, so in that sense, the fix to the problem would probably require a change to the MityDSP BSP. This is good news since you can build the BSP but right now it is not real helpful since it is not clear what the needed changes are.</p>
<p>If we knew what snippets of code from the BSP are used when the ClockPeriod function is called, then a change might be possible. I checked on Foundry27 for a reference to a problem like this and found the following:</p>
<p><a class="external" href="http://community.qnx.com/sf/discussion/do/listPosts/projects.bsp/discussion.bsp.topc8003">http://community.qnx.com/sf/discussion/do/listPosts/projects.bsp/discussion.bsp.topc8003</a></p>
<p>The code attached to the posting changed the invert_timer_freq() function in bsp-mitydsp-omap-l138-src/src/hardware/startup/lib/invert_timer_freq.c as follows:</p>
<p>Old:<br /><pre>
unsigned long rate;
unsigned long rem;
unsigned long div;
unsigned long quot;
</pre></p>
<p>New:<br /><pre>
unsigned long rate;
unsigned long long rem;
unsigned long div;
unsigned long long quot;
</pre></p>
<p>This apparently prevents some overflows that may contribute to the problem. It doesn't really sound like this would fix all the problems you are seeing, but it might help. Could you please try this and let me know how it goes? It would also be interesting to print out the syspage to see how calling ClockPeriod changes the system values related to time. (e.g. use the command <code>pidin syspage</code>)</p>
<p>Hope this helps.</p>
<p>John</p> Software Development: RE: ClockPeriodhttp://support.criticallink.com/redmine/boards/13/topics/842?r=860#message-8602011-10-13T12:33:02ZRob Gillisrobg@jwfishers.com
<p>John,</p>
<p>Actually, the point I was trying to make is that changing the system tick using ClockPeriod confuses the OS concept of time, which shouldn't happen. Using the attached program this is what happens:</p>
<ol>
<li>./clock_period<br />ClockPeriod: 999999 nsecs <- 1 millisecond tick</li>
<li>sleep 5 <- sleeps for 5 seconds (observed)</li>
</ol>
<ol>
<li>./clock_period 10000000 <- 10 millisecond tick</li>
<li>./clock_period<br />ClockPeriod: 9999999 nsecs</li>
<li>sleep 5 <- sleeps for < 1 second (observed)</li>
</ol>
<ol>
<li>./clock_period 200000 <- 200 usec tick</li>
<li>sleep 5 <- sleeps for 25 seconds (observed)</li>
</ol>
<p>As you can see, changing the system tick period to anything other than 1 millisecond causes the sleep utility to malfunction. If I just rebuild this program for my x86 CPU/BSP, sleep functions correctly no matter what the system tick is running at.</p>
<p>So, to me this means the problem is either with the MityDSP BSP or the ARM-specific part of QNX. All I was asking is if you could help me either confirm or eliminate the BSP as a problem. Or if you have any other theories I'd certainly be willing to listen.</p>
<p>Thanks,<br />Rob</p> Software Development: RE: ClockPeriodhttp://support.criticallink.com/redmine/boards/13/topics/842?r=854#message-8542011-10-13T09:16:43ZJohn Pruitt
<p>Rob,</p>
<p>I don't have experience trying to change the clock period. The documentation does seem to indicate that making the period very small can result in significant overhead in the system from all the interrupts. (see clock_setres() and <a class="external" href="http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/kernel.html">http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/kernel.html</a>)</p>
<p>I have usually used the ClockCycles() function in order to do more precise timing.</p>
<p>John</p> Software Development: RE: QNX BSP Timershttp://support.criticallink.com/redmine/boards/13/topics/841?r=853#message-8532011-10-13T08:54:18ZJohn Pruitt
<p>Rob,</p>
<p>I don't know of a feature like this. I have always just used the CLOCK_REALTIME.</p>
<p>John</p> Software Development: ClockPeriodhttp://support.criticallink.com/redmine/boards/13/topics/8422011-10-11T17:08:31ZRob Gillisrobg@jwfishers.com
<p>Hello,</p>
<p>I am having problems changing the system clock period using the QNX BSP. When I try to change it using the ClockPeriod function, it sets a value that confuses QNX as to the correct time. For example, if I try to change the period from 1 millisecond to 50 microseconds, QNX will run 20x slower, tested using the sleep utility from the command line.</p>
<p>I've attached the test program that I used. I ran this same program on an x86 system with no issues.</p>
<p>Thanks,<br />Rob Gillis</p> Software Development: QNX BSP Timershttp://support.criticallink.com/redmine/boards/13/topics/8412011-10-11T14:30:32ZRob Gillisrobg@jwfishers.com
<p>Hello,</p>
<p>I have a need for a timer that supports a higher resolution than QNX CLOCK_REALTIME. It will be used for high accuracy timestamps, but probably will not need to drive an interrupt.</p>
<p>Is a feature like this already supported in the MityDSP QNX BSP?</p>
<p>Thanks,<br />Rob Gillis</p> Software Development: RE: 375 MHzhttp://support.criticallink.com/redmine/boards/13/topics/683?r=685#message-6852011-08-11T16:45:25ZRob Gillisrobg@jwfishers.com
<p>Hi John,</p>
<p>You're right, I was referring to user values, not register values. I have it running at this point, but I2C1 is affected by the CPU clock change, I think it is I2C0 connected to AUXCLK.</p>
<p>Does the BSP automatically handle the SPI Flash at the new speed, or will this also need to change?</p>
<p>Thanks</p> Software Development: RE: 375 MHzhttp://support.criticallink.com/redmine/boards/13/topics/683?r=684#message-6842011-08-09T17:13:45ZJohn Pruitt
<p>Rob,</p>
<p>I checked on the numbers and my chart consistently shows numbers 1 less than yours but I think the chart is for the actual register values and you are showing the user values. So yes, your numbers for 372 and the plldiv3 values seem correct.</p>
<p>I2C1 appears to run off the AUXCLK which is 24 MHZ (CLKIN) regardless of what the PLL values are so it should not need modification. Most other peripherals will probably need modifications to reflect their new clock values.</p>
<p>Please post the last question to the FPGA forum.</p>
<p>Thanks.</p> Software Development: 375 MHzhttp://support.criticallink.com/redmine/boards/13/topics/6832011-08-09T16:17:57ZRob Gillisrobg@jwfishers.com
<p>Hello,</p>
<p>Following your recent BSP changes, I have modified our BSP to support the 375 MHZ L138 board.</p>
<p>It appears that I cannot actually get 375 MHz, but 372 is achievable using prediv=2, mult=31, and postdiv=1. Is this correct?</p>
<p>I assumed that the FPGA cannot run faster than 100 MHz, so I set plldiv3=4, which is 93 MHz. Is this also correct?</p>
<p>I made corresponding UART speed mods, do any other peripherals need to change? We using I2C1, and it is running Ok so far on new BSP.</p>
<p>I reused Critical Link VHDL code for the EMIFA bus core. If I'm running at 93MHz instead of 100MHz previously, are there any VHDL code changes that need to be made or will everything be Ok as is? (let me know if I should post this last question to FPGA forum instead...)</p>
<p>Thanks,<br />Rob Gillis</p> Software Development: RE: 1st time boot uphttp://support.criticallink.com/redmine/boards/13/topics/514?r=539#message-5392011-06-30T10:44:17ZMark Lyonmlyon@draper.com
<p>Confirmed serial works - thanks.</p> Software Development: RE: 1st time boot uphttp://support.criticallink.com/redmine/boards/13/topics/514?r=526#message-5262011-06-29T16:44:06ZJohn Pruitt
<p>Mark,</p>
<p>A new BSP has been posted. The serial port driver has been changed so that with a -M option, it will not enable the modem state interrupt. For some reason, on the newer revision board/module, there are a lot of these interrupts and when enabled, it caused problems. If you start with a new BSP import, the -M changes are automatic. If you just unzip the files over your existing files, then you will need to manually change the .bsh file to add the -M option to the devc-ser8250 lines.</p>
<p>The new BSP also includes support for changing the processor speed to 456MHz. See the wiki page for instructions on how to make use of this.</p>
<p>Hope this helps.</p> Software Development: RE: 1st time boot uphttp://support.criticallink.com/redmine/boards/13/topics/514?r=525#message-5252011-06-29T15:08:39ZMark Lyonmlyon@draper.com
<p>Great, thanks.<br />FWIW I've verified USB and Ethernet works fine. I can comment out all the ports and run from the serial port as setup by u-boot, and I can telnet in too.</p> Software Development: RE: 1st time boot uphttp://support.criticallink.com/redmine/boards/13/topics/514?r=524#message-5242011-06-29T15:04:39ZJohn Pruitt
<p>Mark,</p>
<p>It has been a little while and I wanted you to know that we have reproduced this problem and are working on a fix.</p> Software Development: RE: OMAP I2Chttp://support.criticallink.com/redmine/boards/13/topics/521?r=522#message-5222011-06-28T12:25:21ZJohn Pruitt
<p>Rob,</p>
<p>The two utilities are convenient for easy command-line or script-based access to the I2C for simple control functions. The utilities are very simple-minded and don't try to deal with interrupts or offer flexibility with respect to clock speeds. When their operating conditions are met though, they are easy to use. It probably would have been better to make the commands use the driver instead of going direct to the hardware.</p>
<p>For general-purpose use, it is probably better to use the QNX driver. For testing and experimenting, the utilities can be handy.</p> Software Development: OMAP I2Chttp://support.criticallink.com/redmine/boards/13/topics/5212011-06-28T12:11:07ZRob Gillisrobg@jwfishers.com
<p>Hello,</p>
<p>The MityDSP QNX BSP starts up the IC2 QNX driver, but also has two utilities (i2c_get, i2c_set) that bypass the QNX driver. Why are there two different methods for accessing I2C interface? I'm writing some code to communicate with an I2C EEPROM, does it matter which method I use? Is one way more supported/tested than the other?</p>
<p>Thanks,<br />Rob Gillis</p> Software Development: RE: 1st time boot uphttp://support.criticallink.com/redmine/boards/13/topics/514?r=519#message-5192011-06-27T13:58:18ZMark Lyonmlyon@draper.com
<p>...one more thing... Linux boots up fine, and reports:<br /><pre>
Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0x1c42000 (irq = 25) is a 16550A
serial8250.0: ttyS1 at MMIO 0x1d0c000 (irq = 53) is a 16550A
console [ttyS1] enabled
serial8250.0: ttyS2 at MMIO 0x1d0d000 (irq = 61) is a 16550A
</pre></p> Software Development: RE: 1st time boot uphttp://support.criticallink.com/redmine/boards/13/topics/514?r=518#message-5182011-06-27T13:54:55ZMark Lyonmlyon@draper.com
<p>I am currently running an unmodified boot script, the above section matches.</p>
<p>A log message immediately after <br /><pre>
# Uart1
devc-ser8250 -e -F -S -b115200 -c150000000/16 0x01d0c000^2,53
</pre><br />doesn't appear.</p>
<p>pidin syspage returned the text in the attached file</p> Software Development: RE: 1st time boot uphttp://support.criticallink.com/redmine/boards/13/topics/514?r=517#message-5172011-06-27T12:02:35ZJohn Pruitt
<p>If you are seeing the Welcome banner, you should be through the start-up code and into the qnx kernel. By default, the boot script looks something like this:<br /><pre>
#######################################################################
## Create a symbolic link for the file /usr/lib/ldqnx.so.2
#######################################################################
procmgr_symlink ../../proc/boot/libc.so.3 /usr/lib/ldqnx.so.2
#######################################################################
## Give the Welcome message
#######################################################################
display_msg Welcome to QNX Neutrino 6.5 on the Critical Link MityDSP OMAPL138 Board
#######################################################################
## SERIAL driver (UART x)
## uncomment the appropriate line depending on which uart is being used.
## Differences are with the base address and irq number.
## assumes pin mux is setup correctly. (see init_hwinfo.c in startup code)
#######################################################################
# Uart0
# devc-ser8250 -e -F -S -b115200 -c150000000/16 0x01c42000^2,25
# Uart1
devc-ser8250 -e -F -S -b115200 -c150000000/16 0x01d0c000^2,53
# Uart2
# devc-ser8250 -e -F -S -b115200 -c150000000/16 0x01d0d000^2,61
waitfor /dev/ser1
reopen /dev/ser1
slogger
pipe
#######################################################################
## Create any extra uart devices. Uncomment as needed.
#######################################################################
# Uart0
# devc-ser8250 -u2 -e -F -S -b115200 -c150000000/16 0x01c42000^2,25
# waitfor /dev/ser2
# Uart1
# devc-ser8250 -u3 -e -F -S -b115200 -c150000000/16 0x01d0c000^2,53
# waitfor /dev/ser3
# Uart2
# devc-ser8250 -u4 -e -F -S -b115200 -c150000000/16 0x01d0d000^2,61
# waitfor /dev/ser4
#######################################################################
## I2C driver
#######################################################################
display_msg Starting I2C0 Services
</pre></p>
<p>If you are not seeing the "Starting I2C0 Services" message, then it must be stuck in the waitfor /dev/ser1. You could try putting in more display_msg lines to verify this.</p>
<p>Have you made changes to the boot script?</p>
<p>It might be useful to print out the system page. You could try the command: "pidin -syspage" before the devc-ser8250 line in the boot script. It looks like the uart is working (probably left-over from u-boot and the startup code) and then has problem in the kernel initialization. I have not seen a problem like this before unless somehow the different initializations are not all trying to do the same thing. (e.g. startup code uses one uart but boot script uses something else)</p>
<p>Hope this helps.</p> Software Development: RE: 1st time boot uphttp://support.criticallink.com/redmine/boards/13/topics/514?r=516#message-5162011-06-27T11:45:38ZMark Lyonmlyon@draper.com
<p>Wow - thanks for the fast reply.<br />I do want to use UART0, I was just trying that to see if it was the problem.</p>
<p>I am running a 80-000297 MityDSP dev kit with a L138-FG-225-RC MityDSP L138F 456MHz module.</p>
<p>I am hooked up to the 10-pin header on the dev kit, which I believe is wired to UART1.<br />I believe UART2 goes to the RS-485 header.<br />Not sure where UART0 goes to.<br />I did not change the pinmux.</p>
<p>u-boot shows 1 serial port available<br /> serial 80000003 SIO stdin stdout stderr</p> Software Development: RE: 1st time boot uphttp://support.criticallink.com/redmine/boards/13/topics/514?r=515#message-5152011-06-27T11:35:40ZJohn Pruitt
<p>Mark,</p>
<p>Which board are you using? <br />Are both uart0 and uart1 available? <br />Is u-boot using uart0? <br />Did you change the pinmux configuration to turn on uart0?<br />The boot script will also need to change to specify uart0 instead of uart1. Unfortunately, the console uart is specified in many places and all have to be changed.</p> Software Development: 1st time boot uphttp://support.criticallink.com/redmine/boards/13/topics/5142011-06-27T11:27:42ZMark Lyonmlyon@draper.com
<p>I have followed the directions in the Wiki for booting up the MityDSP board, and I get as far as the banner before everything hangs up:</p>
<p>Welcome to QNX Neutrino...</p>
<p>I've tried changing the configuration to Uart0 from Uart1, but I do not get any console messages past the devc-ser8250 serial driver configuration command in the startup script.</p> Software Development: RE: FPGA Driverhttp://support.criticallink.com/redmine/boards/13/topics/255?r=299#message-2992010-12-03T11:14:14ZJohn Pruitt
<p>Rob,</p>
<p>I posted a new bsp which includes an fpga driver. See the <a class="external" href="http://support.criticallink.com/redmine/projects/arm9-qnx-platforms/wiki/Board_Support_Package">http://support.criticallink.com/redmine/projects/arm9-qnx-platforms/wiki/Board_Support_Package</a> wiki page for the new bsp and instructions on how to use the new fpga-omapl1xx driver.</p>
<p>Hope this helps.</p>
<p>John</p> Software Development: RE: FPGA Driverhttp://support.criticallink.com/redmine/boards/13/topics/255?r=265#message-2652010-11-22T09:00:41ZJohn Pruitt
<p>Rob,</p>
<p>Will do.</p>
<p>By the way, it is possible to have uboot load the fpga image when it is booting. I have used this on boards where the fpga needed to be loaded in order to get ethernet access for uboot but you could use the same mechanism for anything else.</p>
<p>The important step is that there is an environment variable in uboot named "bootfpga" which is "run" when uboot is coming up. You can put whatever commands you want in the command. So you could have the command read the fpga image from NOR flash and then load it into the fpga.</p>
<p>For example, if you had done the following to store the fpga image into flash:</p>
<p>'tftpboot 0xc0000000 YourFPGAImage.bin; sf probe 0; sf erase 0x780000 0x80000; sf write 0xc0000000 0x780000 0x71544'</p>
<p>Then you could do the following to have it automatically loaded when uboot comes up:</p>
<p>setenv bootfpga 'sf probe 0; sf read 0xc0000000 0x780000 0x71544; loadfpga 0xc0000000 0x71544'</p>
<p>Hope this helps.</p>
<p>John</p> Software Development: RE: FPGA Driverhttp://support.criticallink.com/redmine/boards/13/topics/255?r=264#message-2642010-11-22T08:44:55ZRob Gillisrobg@jwfishers.com
<p>That timeframe works fine for me, I'll keep loading via u-boot until then. Let me know when it's available...</p>
<p>Thanks,<br />Rob</p> Software Development: RE: FPGA Driverhttp://support.criticallink.com/redmine/boards/13/topics/255?r=263#message-2632010-11-22T08:41:02ZJohn Pruitt
<p>Rob,</p>
<p>The ability to do the basic fpga commands and load an image sounds like a good starting point and it seems to match with what you are looking for. What is your timeframe? I may not be able to get to this until the latter part of next week. Will this work or do you need it sooner?</p>
<p>Thanks.</p>
<p>John</p> Software Development: RE: FPGA Driverhttp://support.criticallink.com/redmine/boards/13/topics/255?r=262#message-2622010-11-22T08:29:27ZRob Gillisrobg@jwfishers.com
<p>Hi John,</p>
<p>I'm not using the FPGA core detection feature in my design. All I require is the ability to load the FPGA and verify that the configuration is correct. Is that what you're planning?</p>
<p>Regards,<br />Rob</p> Software Development: RE: FPGA Driverhttp://support.criticallink.com/redmine/boards/13/topics/255?r=258#message-2582010-11-18T18:25:05ZJohn Pruitt
<p>Rob,</p>
<p>The Linux FPGA driver has not been ported to QNX yet. Any capability added would probably just be enough to reload the FPGA while QNX is running. Detecting the cores and creating devices for them is not planned for QNX.</p>
<p>When do you need this capability?</p>
<p>Thanks.</p>
<p>John</p> Software Development: FPGA Driverhttp://support.criticallink.com/redmine/boards/13/topics/2552010-11-18T14:03:23ZRob Gillisrobg@jwfishers.com
<p>Hello,</p>
<p>Has the Critical Link Linux FPGA driver been ported to QNX yet? Or is there at least some method of programming/verifying the FPGA once QNX is running?</p>
<p>Thanks</p>