Setting External Bus Frequency on Colibri T20

Hello,


I have received the GMI driver for External Bus of the Colibri T20 from Toradex ARM support.
I have been able to integrate it into the kernel and am able to access it at /dev/gmi as a character special file. I have also written a small utility to read/write and issue ioctl calls to the driver.



I am trying to use LPC1768 (an ARM based micro-controller) to send character data (ASCII encoded) to the T20 external bus. The LPC1768 sends “Hello”, in an infinite loop. The LPC1768 is send its data at 72MHz. What I should be expecting to see when I read from the /dev/gmi is the characters that were sent. Instead what I see is garbage data. This seems to be because there is a mismatch in operating frequency.



Question 1)

What is the default frequency at which the external bus is operating when the driver is loaded?

How do I find out the frequency of the external data bus on T20?



Question 2)

How do I configure the frequency of the external bus.



Question 3)

The following lines in the driver source code seem to have something to do with the frequency:

		case GMI_IOCTL_SPEED_LO:
			pr_info("gmi-chardev: ioctl(): GMI_IOCTL_SPEED_LO\n");
			inst_info->timing0_default = 0xD0A073A8;
			inst_info->timing0_read = 0xD0A073A8;
			//inst_info->timing1_default = 0x00101010;
			//inst_info->timing1_read = 0x00101010;
			inst_info->timing1_default = 0x00141010;
			inst_info->timing1_read = 0x00141010;
			//snor_tegra_writel(c, c->timing0_default, TEGRA_SNOR_TIMING0_REG);
			//snor_tegra_writel(c, c->timing1_default, TEGRA_SNOR_TIMING1_REG);
			break;

		case GMI_IOCTL_SPEED_MED:
			pr_info("gmi-chardev: ioctl(): GMI_IOCTL_SPEED_MED\n");
			inst_info->timing0_default = 0xA0A05585;
			inst_info->timing0_read = 0xA0A05585;
			inst_info->timing1_default = 0x00050406;
			inst_info->timing1_read = 0x00050406;
			//snor_tegra_writel(c, c->timing0_default, TEGRA_SNOR_TIMING0_REG);
			//snor_tegra_writel(c, c->timing1_default, TEGRA_SNOR_TIMING1_REG);
			break;

		case GMI_IOCTL_SPEED_HI:
			pr_info("gmi-chardev: ioctl(): GMI_IOCTL_SPEED_HI\n");
			inst_info->timing0_default = 0xA0A02020;
			inst_info->timing0_read = 0xA0A02020;
			inst_info->timing1_default = 0x00040200;
			inst_info->timing1_read = 0x00040200;
			//snor_tegra_writel(c, c->timing0_default, TEGRA_SNOR_TIMING0_REG);
			//snor_tegra_writel(c, c->timing1_default, TEGRA_SNOR_TIMING1_REG);
			break;

What do the values for timing0_default, timing0_read, timing1_default, timing1_read represent. If they represent timing, then are they in millisec or usec or Hz? Also why are three modes (HI, MED, LO) provided?



Question 4)

What voltage levels define logic 1 and 0 on the external bus?




Attachments:

  1. The source code for the driver. link
  2. Code for the utility I am using to read data from the bus. link

I hope someone from the Toradex team can answer these questions because I cannot find answers to these questions elsewhere.

Your help is greatly appreciated.

Thank you.

I apologize for the delayed response.

Answer to Q1:

The default clock frequency is 86.5MHz.

Answer to Q2:

You can modify the nor clock by editing the clock init table in board-colibri_t20.c. Note that the entry defines both the parent clock and the nominal rate which must be derived from the parent clock through two available dividers. The parent clocks available on the snor clock mux are: PLL-P (408MHz), PLL-C (600MHz), PLL-M (800MHz), M-Clk. For more detail, refer to the Tegra 2 Technical Reference Manual.

Answer to Q3:

These settings actually have nothing to do with frequency (perhaps poorly named), they are simply 3 different timing presets. Most of the values defined are the # of clocks that various signals are held as per the bus protocol. For more detail, refer to the Tegra 2 Technical Reference Manual.

Answer to Q4:

All signalling is 3.3V logic (0V low, 3.3V high). The polarity of some signals can be inverted.

So can I safely change the setting:

{"nor",		"pll_p",	86500000,	true},

to 72Mhz as in:

{"nor",		"pll_p",	72000000,	true},

How can I tell what range of frequencies are safe to use here?

Yes, you can always measure the resulting clock to verify that its an adequate frequency.

Thank you for all your help.