Activity
From 11/08/2010 to 12/07/2010
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...
11/19/2010
- DK 12:14 PM Software Development: RE: Driver Development Procedure
- Mike,
For some reason the source gets messed-up when pasting into the reply box. Therefore, I have attached the make files. Note prior to compiling I export the location of the Linux tree as follows:
export KERNEL_ROOT=/home/stud...
11/18/2010
- DK 07:22 PM Software Development: RE: Driver Development Procedure
- Mike,
Thanks for your fast reply. I have installed the 32-bit GCC running on Fedora 9. Also I have successfully compiled and tested hello world, an application and shared libraries. Uname generates the following response:
[stude... - MW 06:56 PM Software Development: RE: Driver Development Procedure
- Hi David,
There's no magic with the kernel sources we're using. Your makefile looks OK to me.
This is just a guess, but the error messages suggest that perhaps your trying to use the wrong toolchain (64 bit on a 32 bit host). Ar... - I need to create a loadable Linux module that runs on the ARM9 of the MityDSP-L138 and accesses the FPGA. Preferrably the build would be performed "out-of-tree" such that an environment variable references the angstrom kernel tree. I h...
- DV 03:25 PM Software Development: RE: I2C Board Support Package
- Got the new kernel. Compiled and loaded it onto the board. Most things work, but i2cdump seems to have changed. My hardware person (aka John) indicates that his analyzer no longer sees the bus toggle when the dump command is run. /sys/de...
11/16/2010
- TC 07:44 AM Software Development: RE: I2C Board Support Package
- Hi Simon -
The latest version of our kernel is included in the tarball on the BSP wiki page located here:
http://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Board_Support_Package
Tom
11/15/2010
- MP 10:34 PM Software Development: RE: Boot loader on NAND instead of NOR
Hi Simon,
It is still a good idea to hook up the MDIO pins to the PHY. The same two MDIO pins used in MII mode are also used in RMII mode. So the majority of the RMII signals would route through the FPGA, but the two MDIO pins wou...- ST 09:36 PM Software Development: RE: Boot loader on NAND instead of NOR
- Hey Mike,
Yes the RMII is a good alternative. When we will be there, I will probably ask for some support. What we are planning to use are these peripherals
GP0: Used for parallel access to ADCs
PWM0
RMII: Ethernet
UART0: RS485
... - MP 05:34 PM Software Development: RE: Boot loader on NAND instead of NOR
Hi Simon,
While it is indeed possible for the OMAP-L138 CPU to boot from NAND, this is not a boot mode that Critical Link supports on the MityDSP-L138 SoM. It would take both a minor change to the hardware assembly, and boot softwa...
11/12/2010
- DV 03:36 PM Software Development: RE: I2C Board Support Package
- Tried to patch the changes from that file into the kernel posted under Files on this site. Syntax errors on DA850_GPI05_14 and SYSTEM_RESET. Since I still can't "git" could you post a copy of the "most recent version of the kernel". I'll...
- DV 02:06 PM Software Development: RE: Audio help needed
- Please ignore the previous, incredibly stupid question. My mistake is not realizing that it's the stuff in the Kconfig's that goes into the .config with the prefix CONFIG_ added. I need to change the Kconfig's, not the .config.
11/11/2010
- Hi,
One of the big problem I am facing right now is the fact that both PWM modules aren't usable at all. PWM 0 is lost for ethernet and PWM 1 is lost because of the chip select of the NOR. We know we could write a PWM core for the FPG... - MW 07:39 PM Software Development: RE: Loading a New Kernal
- No. If you do this you will erase the UBL and u-boot. Please don't execute this command as you have typed.
Look at the bottom section of this "wiki page":http://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Linux_Ker... - MW 06:53 PM Software Development: RE: I2C Board Support Package
- If you look in the most recent version of the kernel in the "arch/arm/mach-davinci/board-mityomapl138.c":http://support.criticallink.com/gitweb/?p=linux-davinci.git;a=blob;f=arch/arm/mach-davinci/board-mityomapl138.c;h=3afb37a48bf56a7bb9...
- JM 05:51 PM Software Development: RE: I2C Board Support Package
- Ok I got the I2C tools loaded and working. Out issue is that the SYS_RESET_N ( GP5[14] )signal that comes from the OMAP is always lowing holding the Audio chip in reset. I connected this to our audio chip only because you connected it ...
- DV 06:49 PM Software Development: RE: Audio help needed
- Well, most of the git problem seems to be at our end. Some router close to us seems to be traffic shaping us to zero bandwidth.
I'm having trouble with the kernel. I've edited the sound/soc/davinci/Kconfig, added the new "type". I did...
11/09/2010
- MW 08:12 PM Software Development: RE: Audio help needed
- Hi Dennis,
Regarding the audio driver, it sounds like you have a pretty solid handle on the code. The bottom line is, you will need to actually modify the kernel code in the sound directory (KConfig, and the davinci-evm.c file) to en... - DV 07:02 PM Software Development: RE: Audio help needed
- Still stuck on the sound. I looked at the davinci-evm.c and the 3x is called out in that file, however, the Kconfig in that directory doesn't allow the mityomap as an option to allow that file to be compiled. In fact it calls out a varie...