Activity
From 11/21/2010 to 12/20/2010
12/14/2010
- DV 06:40 PM Software Development: RE: I2C Board Support Package
- I've been playing with the kernel trying to narrow down the problem. With the new kernel I can get i2cdump -y 1 0x51 to work by modifying mityomapl138_mcasp_pins back to the value of the 2010.05 kernel. I don't understand why this change...
12/13/2010
- I have downloaded the u-boot snapshot. Can someone tell me the build command sequence in order to support the MityDSP L138 module? My end goal is to build the Linux kernel; however I get an error during this process indicating mkimage ...
12/10/2010
- MW 07:41 AM Software Development: RE: I2C Board Support Package
- I'm not sure if that's true. The I2C lines are required in order to manage the on-board power controller needed for core voltage adjustments. I will check today.
Would it be possible for you to provide (offline, via email or some o...
12/09/2010
- DV 07:40 PM Software Development: RE: I2C Board Support Package
- I'm trying to dig through the two kernels to see what the difference is w.r.t the i2c bus. It looks like the 2010.05 kernel did not try to activate the i2c lines going for the SOC, while the 2010-10-12 does try to activate those lines. A...
- MW 05:33 PM Software Development: RE: Basic Driver Virtual Addressing Question
- You might want to check the fpga_ctrl.c file for an example, or check the online manual for "Linux Device Drivers":http://lwn.net/Kernel/LDD3/ which is extremely helpful.
Short answer is that you need to map in IO regions (physical ad... - I have written a simple "hello world" driver and I am trying to display the value of the OMAP REVID register from the init function. I assigned the physical address to a pointer; however a segmentation fault is generated when memory is ...
- MW 05:27 PM Software Development: RE: Loading FPGA
- Hi David,
Currently, there is a bug in the fpga_ctrl.ko driver that could result in spurious interrupts if you re-program the FPGA a second time (after issuing a "3" / probing command to /sys/devices/fpga_ctrl/cmd). This is due to th... - DK 05:07 PM Software Development: RE: Loading FPGA
- Has anybody tried the online procedure "Using Linux drivers to load the FPGA?" I get an infinite printf loop after reset is commanded as follows:
# cat /proc/modules
fpga_ctrl is displayed with live status
# echo "1" > /sys/dev...
12/07/2010
- DV 06:11 PM Software Development: RE: I2C Board Support Package
- I'm realizing I'm not clear on the hardware. Is it the card that is "Rev B" or the board the card is seated on? Is it the card that contains address 0x51 or the board the card is seated on? I do have two different cards, they have differ...
12/04/2010
- MW 12:52 PM Software Development: RE: I2C Board Support Package
- Hi Dennis,
I tried the same steps as you listed above on a revision A board as well as a C board and don't see this behavior. You are doing this on an unmodified rev-B board?
I will see if I can grab another revision B and repeat t... - MW 12:33 PM Software Development: RE: MityDSP Memory Map
- The chip select 5 address space starts at 0x66000000.
The memory map for the MityDSP-L138 (the OMAP-L138 Processor) can be found in the "OMAP-L138 device specification":http://www.ti.com/lit/gpn/omap-l138 on "TI's Website":http://www....
12/03/2010
- Does anybody know the memory map of the MityDSP? I would like to test FPGA functionality added by our HW designer at chip select #5. Note I am testing a Linux driver running on the ARM9.
Thanks,
Dave - DV 04:15 PM Software Development: RE: I2C Board Support Package
- I backed up and repeated my steps today.
1) Stock kernel on the rev B card: i2cdump -y 1 0x51 works.
Presumably this is the kernel from the "release 2010.05"
However that kernel did not have the
>Look for the text "SYSTEM_RESET"... - MW 10:24 AM Software Development: RE: I2C Board Support Package
- Unfortunately, the Rev-B industrial I/O boards do not have anything hooked to the I2C0 port outside of the SOM.
Rev-C boards moved the I2C interface from the DVI controller chip to I2C0 away from the FPGA I/O pins.
I think if you ...
12/02/2010
- DV 07:08 PM Software Development: RE: I2C Board Support Package
- Sorry, did not manage to dig that out of the kernel. What I could use now as a sanity test is an i2cdump address of some chip on the Industrial I/O board, just to check that I can get the standard configuration with the standard kernel t...
- MW 06:47 PM Software Development: RE: I2C Board Support Package
- The 1 does indicate which bus. It tells i2cdump to open "/dev/i2c-1" instead of "/dev/i2c-2". It is used to append a number to "/dev/i2c-" in the program when opening the device node.
The I2C bus number that is assigned in the kerne... - DV 06:26 PM Software Development: RE: I2C Board Support Package
- The board rev is the same, a few differences with some of the hex codes. But doesn't the 1 in that command indicate which bus should be probed? Wouldn't that probe i2c1 instead of i2c0?
- MW 06:02 PM Software Development: RE: I2C Board Support Package
- OK. Looks like your I2C0 port is up and running and is communicating with the on-board devices in the kernel.
Try running: - DV 05:42 PM Software Development: RE: I2C Board Support Package
- Here it is:
- MW 05:31 PM Software Development: RE: I2C Board Support Package
- I2C0 is actually /dev/i2c-1 (bus numbering for i2c starts at 1 in the kernel, it's a bit arbitrary actually).
There should be 2 devices connected to i2c-1. One is at address 48. That is the voltage regulator. The second one is at a... - DV 04:46 PM Software Development: RE: I2C Board Support Package
- So my problem is I'm only seeing /dev/i2c-1 after the boot.
- JM 04:36 PM Software Development: RE: I2C Board Support Package
- We are using I2C0 for both the Audio Chip and the Touch Screen Controller both of which have different I2C addresses than the EPROM
- MW 04:24 PM Software Development: RE: I2C Board Support Package
- There are 2 I2C devices on the OMAP. I2C0 and I2C1. Both are brought out to the edge connector, Which are you using?
If you are getting valid factory configuration data, then u-Boot used I2C0 successfully to read the on board EPRO... - DV 03:47 PM Software Development: RE: I2C Board Support Package
- Still stuck. The dump of the entire set of boot messages is attached. There are only two i2c messages in the boot (1) indicating the /dev entries have been set up and another indicating the Clock is disabled because it is unused. The man...
- DO 04:00 PM FPGA Development: RE: question on base_module.vhd
- Mike,
Thanks, that's exactly what I was looking for. No further questions at this point.
Regards, Dene - MW 03:48 PM FPGA Development: RE: question on base_module.vhd
Q - "Are any of the features or functions designed such that they shouldn't be duplicated in a second version of the module?"
Don't duplicate the DNA function.
Don't duplicate the IRQ function unless you have other interrupt line...- DO 03:32 PM FPGA Development: RE: question on base_module.vhd
- I figure there's a chance that we may want to use some of the cores/drivers in the future. Therefore, my design approach has been to reuse the existing framework components, such as EMFI_iface, MityDSP_L138_top, etc., modifying them as n...
- MW 02:57 PM FPGA Development: RE: question on base_module.vhd
- Hello Dene,
The base module was designed to be plugged into our framework (using the EMIF_Iface.vhd). It does do things like interrupt routing, reading of the DNA signature, and providing DCM reset logic. All of these functions are ... - There seem to be many features and functions in base_module.vhd.
I've been planning to create my own version and leave the existing base_module instantiated.
Are any of the features or functions designed such that they shouldn't be dup...
12/01/2010
- MW 08:13 AM Software Development: RE: I2C Board Support Package
- Hello Mr. Volper,
Are you still stuck on this issue, or did reseating the card resolve the I2C problems?
-Mike
11/30/2010
- MW 04:02 PM FPGA Development: RE: OMAP-L138 EMA_WE vs. EMA_A_RW documentation descrepancy, usage
- Sure, as long as you don't want to reconfigure the FPGA at runtime, you could modify the usage assignment and forget about it's previous functions.
Good luck!
-Mike
- DO 03:54 PM FPGA Development: RE: OMAP-L138 EMA_WE vs. EMA_A_RW documentation descrepancy, usage
- Mike,
In our implementation, we already need to pass some reads and writes through to another FPGA on our "carrier board." This has the potential to be a bottleneck already, and I'm trying to design an approach that minimizes any dela... - MW 03:23 PM FPGA Development: RE: OMAP-L138 EMA_WE vs. EMA_A_RW documentation descrepancy, usage
- I don't see any technical reason why you could not use it, but it is preferable that you do not use the EMA_A_RW pin. Here is why:
The EMA_A_RW pin is connected to the FPGA RDWR_B logic signal and is used during FPGA loading (slave s...
There seems to be a slight discrepancy in how EMA_A_RW is described vs. how it's used.
In one area of TI's documentation, EMA_WE is described as the SDRAM write enable signal, and EMA_A_RW is described as the Async Read/Write contro...
11/29/2010
- MW 07:33 AM FPGA Development: RE: EMA_WAIT usage
- The OMAP-L138 processor includes internal pull-up / pull-down capability on just about every peripheral pin. This was done by TI in order to reduce the need for external pull-up/down resistors on a design and to provide the capability t...
- I believe our design will require use of a wait signal to the processor.
There are two such signals available, one of which is used to support the NAND FLASH.
The existing code in the top level file and the EMIFA_iface file always tri... - MW 07:11 AM FPGA Development: RE: fpga EMIFA interface: BA(1) = EMA_A(14)?
- The FPGA address / data / control signals are indeeded sampled and run off of the EMA_CLK, which is configured for 100 MHz operation by default.
The FPGA code supplied assumes "normal mode" for chip select space 5. You are free to im...
11/28/2010
- DO 07:07 PM FPGA Development: RE: fpga EMIFA interface: BA(1) = EMA_A(14)?
- Thanks,
That section and that document were exactly what I was looking for.
You're right, of course, about the concatenation being to the LS bit;
I create my vectors the same way. I'm juggling dozens of details that
I'm researchin...
11/27/2010
- MW 07:26 PM FPGA Development: RE: fpga EMIFA interface: BA(1) = EMA_A(14)?
- Hi Dene,
Actually, that concatenation puts the assignment of EMA_BA(1) to bit 0 of the address (the LSB) for a 16 bit wide data interface. We typically use little endian style vectors in our VHDL code (e.g. "15 downto 0" instead of "... - I notice in EMIFA_iface.vhd that the EMIFA bank address bit 1 -> i_ema_ba(1) <- is concatenated to the top of the incoming address bus. This looks like it might indeed be the same as the 15 bit of the address bus for SDRAM interfaces, b...
11/23/2010
- DV 08:57 PM Software Development: RE: I2C Board Support Package
- Odd:
- MW 08:14 PM Software Development: RE: I2C Board Support Package
- Oh... and as far as the pinmux, the u-Boot should be configuring the pinmux for I2C0. It will always do that as it needs to read the I2C for the factory configuration, so the kernel should not need to mess with the I2C pins for pinmux.
... - MW 08:13 PM Software Development: RE: I2C Board Support Package
- My guess is that the MAC is a random MAC generated by the kernel because all zeros is an illegal MAC (check the kernel messages with `dmesg`, there may be a message about using a random MAC address).
The factory configuration is store... - DV 07:45 PM Software Development: RE: I2C Board Support Package
- MW 06:35 PM Software Development: RE: I2C Board Support Package
- Hi Dennis,
Which Revision of the Industrial I/O are you using? Rev A Industrial I/O boards have the I2C port of the video hooked through the FPGA, not I2C0 on the OMAP, so you won't get a valid response if you are using a Rev A indus... - DV 05:55 PM Software Development: RE: I2C Board Support Package
- I tried the following experiment. On an Industrial I/O board I replaced the Rev A OMAP card with a fresh out of the package card with a white tag "L138F". Verified the existance of /dev/i2c-1, enabled the network, opkg'd in the i2c-tools...