I2C3 bus verification on SMD design of i.MX53

[VincentChou1z]

Hi!  

We design a board based on i.MX53 SMD design.  In addition to the existing VGA connector wired to I2C3, we wired another LCM module with I2C bus to 5V VGA_I2C and then to the 3.3V I2C3 bus.  However, we are not sure the I2C3 bus works on SMD or not.  Could anyone share his/her experience on using I2C3 bus?  

Also, we know there is a I2C probe command within uboot.  Could anyone tell us how to use i2c related commands in uboot to test chips on I2C3 bus? 

Thanks!

Vincent

[kamejoko80]

Dear Mr Mark,

Thank you very much.

Best Regards.

[TheAdmiral]

DDR3 was designed to allow the use of fly-by topologies. They are very useful for large designs (computer motherboards) that route traces large distance, go through DIM connectors, and connect to a large number of DDR3 ICs.

But this is not necessary for small, portable devices. While Fly-by can be used, there are some disadvantages:

Fly-by requires a termination resistors on the address lines, so this is extra cost for components and assembly that are not necessary in the tree design.

Termination resistors use extra power, which is not desired in portable, battery designs.

These are the two basic reasons for using the tree design in portable devices.

Cheeers

[kamejoko80]

Dear Mr Mark,

Many thanks for your kind help,

May I have one more question, the IMX53 QSB's DDR3 layout is now using tree topology rather than fly-by as another traditional designs, why ?

Thanks in advance.

Best Regards.

[VincentChou1z]

Hi! Mark,

If we want to enable our I2C3 in our kernel, what parameters should I modify in our kernel source code?  Thanks in advance!

Vincent

[VincentChou1z]

I discovered that I have trouble to build a bootable SD environment with L2. 05 but successfully built it with L2. 09. However, L2.05 is the legitimate version freescale suggested to use for SMD board. Any idea?

[TheAdmiral]

>> Have you had any experience to solve the kernel panic issue which uboot and kernel image run to the end and could not mount rootfs?

Sorry, no.

From what I understand, uBOOT is booting correctly on your board, but when you try to load the kernal, you are getting kernel panic. I think it is time to connect a JTAG debugging tool. As a minimum you could look and see if your I2C3 pin muxing registers are set correctly by the uBOOT code.

Vincent Chou said:

Hi! Mark,

I have not replied to your email because I am still struggling to figure out how to build a bootable u-boot, uImage and rootfs based on the i.MX53_SABRE_TABLET_Linux_BSP_UserGuide.pdf.  Have you had any experience to solve the kernel panic issue which uboot and kernel image run to the end and could not mount rootfs? It seems I could create a legitimate rootfs in ltib.  Any suggestion?

Vincent

[TheAdmiral]

If you take the Quick Start schematics and delete U4 & U6, you will be fine. On your new board, route only the traces that need to be routed for 2 chip DDR operations (ie, if you start with an existing layout, remove the stub traces going to pins to the removed chips).

The data strobe trace and data mask trace needs to match up with each 8-bit word to work correctly. So SDQS0 and DQM0 with go with D0 - D7 and so forth. Try to match the trace length of each strobe/mask/data combination as close as possible together. If one trace needs to be slightly longer than the rest, this should be the strobe trace.

The clock signals work in somewhat the same way. They can be independently adjusted with registry settings to have small delays, so that, if necessary, the two chips can be "clocked" at slightly different times. There is no requirement that SDCLK0 go to one particular DRAM or the other. They are not tied to particular address or data bits.

One other quick word of advice. Make sure the operating system you are going to use functions well with the amount of DRAM you are placing down on the boards. My experience is that software teams always want more DRAM capacity, and are never satisfied with less.

[kamejoko80]

Hi,

I'm a newbie.

I'm planning to build an iMX53 custom board (based on IMX53 QSB design). In order to assembly the board easily, can I remove the bottom DDR3 U4 & U6 (nCS1) from the schematic ? is it illegal ?

The iMX53 QSB implemented two differencial clock lines per chip select for Lower 16-bits [15:0] and Upper 16-bits [31:16] difference with another traditional DDR2/DDR3 schematic. I'm confused at this point.

Could you please give me some suggestions ?

Thanks and Best Regards.

[VincentChou1z]

Hi! Mark,

I have not replied to your email because I am still struggling to figure out how to build a bootable u-boot, uImage and rootfs based on the i.MX53_SABRE_TABLET_Linux_BSP_UserGuide.pdf.  Have you had any experience to solve the kernel panic issue which uboot and kernel image run to the end and could not mount rootfs? It seems I could create a legitimate rootfs in ltib.  Any suggestion?

Vincent

[TheAdmiral]

Hi Vincent,

I can tell you that I2C3 does work on the SMD board. I'm sorry that I can't tell you if the drivers are loaded in uBOOT, or in the kernal following uBOOT.You should probably look at the source code for uBOOT and look to see if the pin mux settings for GPIO_3 and GPIO_6 are set for I2C3 operations. The uBOOT command looks like:

i2c mw <Hex address of target IC> <Hex of affected register> <Hex of new command to write>  - to write

i2c md <Hex address of target IC> <Hex of affected register> - to read

But I suspect that only I2C1 is set up in uBOOT.

That's the best I can help you with.

Mark