Activity
From 07/02/2014 to 07/31/2014
07/31/2014
- JC 03:36 PM Software Development: RE: Start Guide : Cannot build helloworld application with eclipse
- Instructions for flashing a new filesystem can be found here:
https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Linux_Root_File_System#Flashing-Image-to-NAND - DB 11:57 AM Software Development: RE: Start Guide : Cannot build helloworld application with eclipse
- After using the older toolchain v4.3.3 and existing ARM filesystem, I was able to get the HelloWorld executable to run on the ARM.
I needed to set up the environment for the v4.3.3 toolchain:
Environment Setup for ToolChains 4.3.3... - MA 12:24 PM Software Development: RE: I2C 0x8 Address
- I've just tried the latest mitydsp-linux-v3.2 from git (without the i2c patches) and that works fine.
- MA 11:04 AM Software Development: RE: I2C 0x8 Address
- Just for clarification, I had reverted all changes to the branch (enabling i2c-2) so 'git status' shows no local modifications.
- MA 10:41 AM Software Development: RE: I2C 0x8 Address
- Yes, it is:
- JC 10:07 AM Software Development: RE: I2C 0x8 Address
- Just to verify this was with the newer mitydsp-linux-v3.2_i2c_wip branch?
- MA 09:55 AM Software Development: RE: I2C 0x8 Address
- That's really strange. The only modifications I made were to baseboard-industrialio.c in order to enable i2c-2:
- JC 08:24 AM Software Development: RE: I2C 0x8 Address
- I tried your steps on the mitydsp-linux-v3.2_i2c_wip with i2c-2 enabled but didn't encounter a hang.
07/30/2014
- JC 01:33 PM Software Development: RE: Start Guide : Cannot build helloworld application with eclipse
- > root@mityomapl138:/var/volatile/tmp# ./HelloWorldCC
> ...
It looks like your using the old filesystem with the new compiler. Which will cause these shared object errors. The latest filesystem can be found in the MDK. Or you can use... - DB 12:48 PM Software Development: RE: Start Guide : Cannot build helloworld application with eclipse
- Jonathan,
Thanks for the reply.
Yes, I’ve followed the Starter Guide. Spent most of last week working through it. Issues w/ Virtual Box and the tool chain slowed me down a bit.
First time checking whether tool chain was installed ... - MA 08:18 AM Software Development: RE: I2C 0x8 Address
- Hi Jonathan, thanks for the testing branch. As our code is still based around the old 2.6.34-rc1 release, it will be while before we can fully port everything and test against the 3.2 kernel. However, I did try the I2C bits and your patc...
07/29/2014
- JC 02:25 PM Software Development: RE: I2C 0x8 Address
- I've created a test branch with my patches for this problem. Could you verify it works for you? Note that branch would need i2c1 enabled.
Branch: mitydsp-linux-v3.2_i2c_wip
http://support.criticallink.com/gitweb/?p=linux-davinci.... - JC 10:24 AM Software Development: RE: I2C 0x8 Address
- Okay I have submitted a bug report to the linux davinci mailing list using some of your procedures and stack trace. Waiting to see what they have to contribute.
- MA 10:12 AM Software Development: RE: I2C 0x8 Address
- Thanks Jonathan, I can confirm that the workaround allows the CPU frequency scaling to work with I2C1 enabled (but not yet accessed).
- JC 09:56 AM Software Development: RE: I2C 0x8 Address
- It appears that the wait_for_completion is the wrong type of synchronization as it currently will always be true as long as there has been a transfer over the i2c bus. It probably intended to make sure that an ongoing transfer completes...
- JC 08:56 AM Software Development: RE: I2C 0x8 Address
- The transition function looks like following. The wait_for_completion call then calls wait_for_common which can be seen in your stack trace.
- JC 08:50 AM Software Development: RE: I2C 0x8 Address
- I can confirm. Made the following changes to the 3.2 kernel and tried changing the frequency. It locks up if you don't access the i2c bus first.
- MA 08:33 AM Software Development: RE: I2C 0x8 Address
- Hi Mike,
??To confirm, you don't see this issue with I2C1 not enabled in you kernel (the "stock" dev kit kernel), correct???
Correct, no such issues with the stock kernel config.
??Also, are you configuring the pin mux in the ... - MW 07:42 AM Software Development: RE: I2C 0x8 Address
- Ok, you didn't mention you are trying to adjust the CPU speed (or I missed it) as your I2C0 access method. That's not quite the same as using I2C0 from the command line via i2c-utils or some other driver access (e.g., the EEPROM). Are ...
- MA 05:44 AM Software Development: RE: I2C 0x8 Address
- Hi Mike, actually our experience is the opposite:
1. Enable I2C1, flash the new kernel and reboot
2. Immediately after reboot, attempt to use I2C0 by setting the processor clock: "echo 456000 > /sys/devices/system/cpu/cpu0/cpufreq/sc... - JC 09:09 AM Software Development: RE: Start Guide : Cannot build helloworld application with eclipse
- Have you followed the instructions located on the wiki? https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Starter_Guide
07/28/2014
- DB 03:13 PM Software Development: RE: Start Guide : Cannot build helloworld application with eclipse
- I'm working through the Starter Guide for the MityDSP-L138 configured with
- VirtualBox 4.3.0 (could not get MityDSP VM with VB 4.3.14 to load on Win7 laptop without errors)
- MityDSP-L138-SDK.ova installed from DVD
- Ubuntu ... - MW 11:55 AM Software Development: RE: I2C 0x8 Address
- Looks like the kernel is configuring the OMAP-L138 I2C slave address as 0x08 (by default, it is 0x00 - illegal - in the TRM).
As the comments and the TRM suggest, it doesn't look like you can disable slave response mode in the OMAP-L1... - AS 11:33 AM Software Development: RE: I2C 0x8 Address
- No worries. I don't think i2c-detect does anything strange with this address. By looking at the code, I don't see any provision for this. It just writes to all the addresses and see what comes back.
I think the transition of the 0x8 i... - MW 11:29 AM Software Development: RE: I2C 0x8 Address
- We're looking at it now. I think that the i2c-tools may be emulating SMBus and trying to run the arbitration scheme at 0x08. We note that the u-Boot utility does not detected at address 0x08 and only sees the PMIC at 0x48 and the EEPRO...
- AS 10:49 AM Software Development: RE: I2C 0x8 Address
- Source : System Management Bus (SMBus) Specification Version 2.0 August 3, 2000 :Appendix C – SMBus device address assignments:
0001 000 SMBus Host System Management Bus Specification v 1.1 December 1998
Does this mean that it is a... - AS 10:20 AM Software Development: RE: I2C 0x8 Address
- OK. So is it a defect on the MityDSP-L138F board, or is it the address of the OMAP I2C bus?
- JC 09:54 AM Software Development: RE: I2C 0x8 Address
- Also on a devkit where the dvi chip was removed the 0x08 address still appears.
- JC 09:52 AM Software Development: RE: I2C 0x8 Address
- Well at the least I can identify the others. 0x38 is the dvi chip, 0x48 is the pmic, and 0x50-58 is the eeprom. When I try to read from the 0x08 address I get all sorts of i2c error messages.
- AS 09:31 AM Software Development: RE: I2C 0x8 Address
- We use a custom baseboard, but the address 0x8 is at the the industrial IO development kit as well:
root@PureVLC:~# i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- 08 -- -- -- -- -- -- ... - MW 08:06 AM Software Development: RE: I2C 0x8 Address
- Did you set the pin-mux settings for the I2C1 lines on the second device in the kernel as well? For the devkit baseboard, they are set to UART2_TXD and RXD to support the RS485 port on J504.
Both the I2C0 and I2C1 ports are exposed o... - AS 07:59 AM Software Development: RE: I2C 0x8 Address
- The problem is that if we enable both I2C interfaces by changing the linux source code by adding the following lines at the "arch/arm/mach-davinci/board-mityomapl138.c"
ret = da8xx_register_i2c(1, &mityomap_i2c_1_pdata);
... - MW 07:55 AM Software Development: RE: I2C 0x8 Address
- What are you using for your baseboard?
- AS 07:46 AM Software Development: RE: I2C 0x8 Address
- I am using MityDSP-L138F board.
- Hi All,
When I run i2cdetect -y 1 I get the following output:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- 08 -- -- -- UU -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -...
07/23/2014
- PS 11:06 PM FPGA Development: RE: fpgautil read Issue
- Hi Mike,
I found the issue. I was updating the edo_out signals only when rd was going high.
From the waveform i found rd signal going high after edo_out is driven on the interface.
It really make sense when updated register v... - MW 08:42 PM FPGA Development: RE: fpgautil read Issue
- Can you post (or email me) you VHDL source related to the loopback register?
Do you have Chipscope? It might be worth using chipscope to track the address / register data through the transfer cycle.
-Mike - I'm using MityDSP-L138 Board. I have implemented a Custom IP in the FPGA board.
I'm using the CS5 ARM Chipselect and using the frame work available in fpga/vhdl directory.
Also, i'm using the fpgautil program in examples dir to read...
07/22/2014
- GG 11:42 AM Software Development: RE: uPP receiving problem
- Hello Silvano,
No, the MDK uPP libraries are not setup to work with the debugger. In your code you can try setting the necessary debug bits, as you pointed out in your last post, after calling the initialize() routine. I remember hav... - SB 08:54 AM Software Development: RE: uPP receiving problem
- The strange behaviour still continue.
When we do not send data to uPP using the FPGA the program does not have the strange stepping.
Whne we send data to uPP the stepping behaviour still remains even if the optimizations are turned off... - SB 03:10 AM Software Development: RE: uPP receiving problem
- Thanks a lot for the suggestion.
I will check with my colleague the VHDL connection.
I also had a check at the optimitations but they are all turned off. It is very strange because it is a very simple program.
Any other suggestion, m...
07/21/2014
- JC 12:41 PM Software Development: RE: uPP receiving problem
- The strange stepping sounds exactly like when optimizations are turned on.
- DR 11:46 AM Software Development: RE: uPP receiving problem
- I'm not a VHDL guy, so I can't say whether this will work as you have it. It sounds like you and your VHDL guy should sit together and verify that it is correct. It's best to do this using ChipScope.
I'm not sure why the code is ste... - SB 11:34 AM Software Development: RE: uPP receiving problem
- Here you can find the VHDL sources.
I cannot help you a lot with VHDL becuse it is developed by a colleague of mine.
Thanks in advance another time to help me.
Silvano - SB 11:19 AM Software Development: RE: uPP receiving problem
- Thanks a lot.
Now the working principles are clearer.
The problem now is that the software has a strange behaviour.
During the debug operations and the step by step execution, sometimes, after the receive() call, it steps itself back ... - DR 11:09 AM Software Development: RE: uPP receiving problem
- Each time you call receive, a DMA is set up to fill the buffer you pass. Once that DMA completes, no data will be transferred into memory until another DMA is queued up.
Typically, you will queue up 2 DMA's and as each completes, ano... - SB 10:08 AM Software Development: RE: uPP receiving problem
- Ok thank you.
I will try to change all the interrupt levels.
Another question is: but once the buffer is filled? What happens? It stops to receive?
Thanks. - DR 10:05 AM Software Development: RE: uPP receiving problem
- I don't see any reason that it wouldn't work, but I have seen issues with some interrupt levels not working. I strongly recommend that you try some different ones.
The receive command is the start from the software point of view.
... - SB 09:59 AM Software Development: RE: uPP receiving problem
- Thanks to have a look.
I have the signal enable and start always active.
I think that therefore is right to set bChanAUseStart to true.
I can check all the interrupt level... but i do not think that is a problem.
But supposing the co... - DR 09:49 AM Software Development: RE: uPP receiving problem
- A couple of things that I see are different from some code that I have working here:
I use nHWInterruptLevel = 7. Perhaps level 4 is already in use...
I use nTskPriorityChanA = 11.
I don't use bChanAUseStart = true. I set this to ... - Dear all,
I am trying to use to uPP to receive data coming from the FPGA.
Attached you can find the code I wrote. Aim of the code should be:
- receive only on the channel A.
- the receiver buffer is 4096 lines and each lines is m...
07/15/2014
- NP 04:39 AM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Hi Jonathan,
Thank you for your patches, it's working for me!
I have applied and successfully rebuilt my kernel.
And almost PRU example from TI can run on my board.
Thanks you very much! ^^
_Regard,
Manh BT
07/14/2014
- JC 11:39 AM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Ngoc,
Can you confirm that this is working for you and i'll move the changes into our main kernel branch?
I also created a wiki page to help future projects [[Using PRU]] - JC 10:51 AM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- gpioToggle test passed when i just ran it. Not sure why.
- JC 10:24 AM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Reran some of the commands to see which fail. The ./PRU_memAccessL3andDDR can cause system segfaults as it appears to use a fixed part of ddr during its test and if a program or linux happens to be residing there then it will be overrid...
- JC 09:11 AM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Running through all the examples, atleast one of them seems to have caused a system segfault as not even reboot was able to run afterwards.
- JC 09:09 AM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Hi Ngoc,
I have been working on getting this to work. So far i've integrated the patches which i've posted to a test branch until we can confirm its working. Please checkout 'mitydsp-linux-v3.2_pruss_wip' branch. Currently it is cr... - NP 04:45 AM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Hi,
Thank you, I'm waiting for your patches. ^^
Regards,
Manh BT - JC 09:25 AM Software Development: RE: uBoot and USB using L138F SoM
- I have been looking into this. It seems that it was a mistake as the added resistor isn't mentioned in our Engineering change request. I noticed the added resistor recently when I was working towards getting the OTG feature working. C...
- SE 03:28 AM Software Development: RE: uBoot and USB using L138F SoM
- OK, the cable that I used was a miniAB to USB A plug which was then attached to a USB A to USB A gender changer (a little crude, but it works).
Dare I ask why did you add a pull down resistor on your revision C board if the specificat...
07/13/2014
- BD 10:18 PM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Hello Manh BT,
The patches Mike described are in the mainline Linux kernel (http://kernel.org/). You can search for those commit hashes via Google to see the required changes.
We are in the process of applying and testing these pat... - NP 09:42 PM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Hi Michael,
Thanks for your information, but where can I get above patches? Is it in Critical Link MDK ?
Regard,
Manh BT
07/11/2014
- JC 01:30 PM Software Development: RE: uBoot and USB using L138F SoM
- As per the On-The-Go spec, the mini USB adapter is supposed to tie the USB_ID pin to GND to indicate it should be put into host mode.
http://en.wikipedia.org/wiki/USB_On-The-Go#OTG_mini_plugs
http://www.amazon.com/Host-Cable-fema... - SE 12:36 PM Software Development: RE: uBoot and USB using L138F SoM
- Yep, loading an image seems to be OK. Next week I'll try the whole image + rootfs and make sure that works too.
Thanks! (sometimes you just need a nudge in the right direction!) - SE 12:20 PM Software Development: RE: uBoot and USB using L138F SoM
- OK, now I get it. There's no resistor on my board pulling the ID pin down to 0V. I've just put a link between pins 4 & 5 on J100 and its all OK now.
I'll try putting an image on there for it to boot from and let you know. - SE 12:07 PM Software Development: RE: uBoot and USB using L138F SoM
- The number is 80-000286RI-2
REV B
S/N 132556
Which bootloader are you using? I've been using my own compilation but that is wholly based on the one taken from the Git repository from your wiki link with no modifications. - JC 12:05 PM Software Development: RE: uBoot and USB using L138F SoM
- Whats the part number of your dev kit? Should be a 80- number.
- JC 12:03 PM Software Development: RE: uBoot and USB using L138F SoM
- I just tested this by first plugging the flash drive into the full size usb port J102. With no luck. Then plugged drive into J100 via adapter cable and it was discovered. See log below.
- SE 11:43 AM Software Development: RE: uBoot and USB using L138F SoM
- I forgot to say that I know that the USB port works because, once in Linux I can mount the drive OK and read/write files etc.
USB drive is plugged into J100 via an adapter cable. - Hi there,
I'm using the L138F SoM on a REV B Industrial I/O board and I am trying to boot from a USB drive. uBoot is configured for USB but when I try:
@usb start@
All I get is:
@(Re)start USB...
USB: scanning bus for devic... - MW 08:31 AM Software Development: RE: How to enable PRU Subsystem on MityDSP-L138F SOM ???
- Hi,
I think we need to add the following patches (from linus tree) to the kernel to instantiate the PRUSS drivers for the L138.
2eb2478d471e45e1d0c8bb3defbf82bf7204e13d uio: uio_pruss: replace private SRAM API with genalloc
8e0d72... - Hi everyone!
I'm using MityDSP-L138F SOM + IO Industrial Board and now trying to work with PRU subsystem of OMAP-L138 processor.
I've found some instructions from:
http://processors.wiki.ti.com/index.php/PRU_Linux...
07/03/2014
- UF 02:45 PM Software Development: RE: uPP delay between transmissions
- It was a cache invalidation issue. Calling BCACHE_wb() solved the problem.
I did find a small bug in the trasmit() code: - DR 08:29 AM Software Development: RE: uPP delay between transmissions
- My first thought on seeing this is that it is probably a cache issue. After you set the values in the buffer, the values are in the cached version of the buffer, but haven't be written to external RAM. When you do the DMA, it doesn't g...
07/02/2014
- UF 06:47 PM Software Development: RE: uPP delay between transmissions
- We cannot get the uPP to work. For test we just use the FPGA to pass the uPP pins to FPGA output pin. The Enable pin works fine, but the Data pins make no sense. Attached is an image showing the Enable pin in pink and a data pin in blue....
- MW 07:19 AM Software Development: RE: uPP delay between transmissions
- Ah, yes, I am sorry I forgot about the EMIFA scheduling delays. You are correct.
If you are using the reference Platform.tci DSP/BIOS configuration from the BSP, try the "IRAM" section.
I believe the L2 (256K total) is setup as 1... - UF 12:55 AM Software Development: RE: uPP delay between transmissions
- We started with EMIFA. We got a delay of 11uSec between transfers as discussed in this post:
https://support.criticallink.com/redmine/boards/12/topics/3903?r=3942#message-3942
This seems way slower than your expectations. Removing ... - SB 11:49 AM Software Development: RE: Linker error on DSP application with Code Composer 6
- Thanks a lot to everybody.
It was a simple linker problem.
Silvano - Hello everybody.
We see an unexpected behaviour during simple debugging operations.
/*
* main.c
*/
#include <stdio.h>
#include <std.h>
#include <log.h>
#include "testcfg.h"
int pippi[1000];
Void main(void)
{
shor...