SYS_RESET_N Signal
Added by John Mladenik over 13 years ago
On your development board you tied the SYS_RESET_N (GP514 or MMCSD0_DAT7) signal to the active low reset on the Audio chip. On our board we did the same thing but we use a different Audio chip that is more suited our needs. Our software guys are unable to set this pin high. It either is low or it floats. I did not see a pullup on this signal anywhere on your schematics. Does this signal need a pullup on it? If not why is it not driven high?
Also can you send me a list of the I2C addresses that are being used especially for the C Rev MityDSP since I only have schematics for the B Rev. I think I know what they are but I found that our I2C Touch screen controller uses the same address space as your power sequence chip (TPS65023RSBT)
Replies (2)
RE: SYS_RESET_N Signal - Added by John Mladenik over 13 years ago
Oh I retried an old version of the Kernal that did drive the SYS_RESET_N HI but none of the I2C worked they all time out. The command I use is "i2cdump -y 1 0x51" and it continuously gave a timeout and retry.
RE: SYS_RESET_N Signal - Added by Michael Williamson over 13 years ago
Hello Mr. Mladenik,
I believe you are working with two types of boards and I'd like to make sure that we are talking about the same thing when we talk about revisions of hardware.
There is the MityDSP-L138F SoM. That is the daughter card. I do not think there are revisions > A in the field for this card.
There is the Industrial I/O board (80-000268...). That is the mother card / host card. This board has revisions through D in the field.
It might be best to call out the serial number and part number for each board (we can determine the variants here from that information) if this is confusing.
For the SYS_RESET_N:
On the OMAP-l138, pin GPIO5_14 defaults (on power up or reset) to having an internal pull up resistor enabled and is then configured as an input / tristated pin. This pin should then be pulled high until the linux kernel CL provides is run.
When the linux kernel CL provides is loaded, the GPIO5_14 pin is pulled low and then driven high. This can be seen in the mityomapl138_setup_mcasp() routine in the arch/arm/mach-davinci/board-mityomapl138.c. We've tested this behavior on several Industrial I/O boards here and have not had a problem with the reset signal. All the newer kernels should be asserting low and then driving this pin high. If the signal were low on the industrial I/O board, then the audio interface and the CAN interface would not work correctly, and we've been able to run both of these interfaces during board level testing here. It might make sense to have your software engineers at a "pr_warn()" command in the board-mityomapl138.c file and verify that the pin operations are being called. How are your software guys trying to configure the pin? Are they trying to use gpiolib, or are they modifying the kernel?
For the I2C Addresses:
On the MityDSP-L138 SoMs, there are 2 devices on the I2C0 port. There is an 256 EEPROM (24AA02-I/MS) at address 1010XXXb (0x50->0x57) and TPS65023RSBT voltage controller at 1001000b (0x48).
On revision C and higher Industrial I/O boards, the TFP410PAP DVI Controller at address 0111000b (0x38) was added to the I2C0 bus. On previous revisions, this chip was attached to general purpose I/O pins routed to the FPGA for MityDSP-L138F based SOMS. The chip was moved to the I2C0 bus of the OMAP in order to support using the DVI controller with the OMAP LCD peripheral on FPGA-less modules.
Hope this helps. I have not been able to reproduce the problem with "i2cdump -y 1 0x51" you are describing using the latest and greatest kernel here.
-Mike
