Problems with GPTIMER2 programmed differently on different Rev A6 boards

GoogleGroups
1

I’m using the BeagleBone as the CPU in a voltage monitoring device.

I created a cape with some SPI A2D devices on it and use the 7 ADC channels in the BeagleBone to increase the number of monitored voltages.

I’m using an Ubuntu user space with a custom kernel to enable three SPI chip selects and both SPI controllers. This is all working fine and has been for some time.

I wasn’t initially using the 7 additional ADC channels, but now I need those additional inputs.

My lab system works fine when I read the ADC channels (the readings are bit wild and I have to do significant filtering on the returned values, but that’s another post…)

But when I tried to build a second system that used the ADC channels, it fails. The TSC (touch screen controller) driver fails to load on two different BeagleBone boards I tried using with the following error:

tsc tsc: clock input less than min clock requirement
tsc: probe of tsc failed with error -22

And when I check earlier in the kernel output, I find this:

OMAP clockevent source: GPTIMER2 at 19200000 Hz

But on the system that works, I see this:

OMAP clockevent source: GPTIMER2 at 24000000 Hz

There were two other diffs in the dmesg:

The RTC wasn’t set so it set the time to year 2000. I tried setting the RTC but this doesn’t seem to have resolved the problem.

And the slower clock led to a lower BogoMIPS…

Calibrating delay loop… 548.86 BogoMIPS (lpj=2744320)
vs
Calibrating delay loop… 437.45 BogoMIPS (lpj=2187264

In both cases, my system is running off 5V power provided through the cape and not from USB power, so this shouldn’t be the power limiting due to USB power limits. I verified that the provided power is 4.9 volts or higher.

I can’t find any u-boot or kernel setting to control this and it doesn’t seem like it’s the USB powered speed limiting documented in the manual.

Does anyone have any idea why two boards boot at 19.2MHz and one system boots at 24MHz?

Any ideas where that configuration setting is coming from? I tried moving the microSD card from the working (24MHz) system to the failing (19.2MHz) system and the “slow” system still boots slow, so it doesn’t seem to be anything in the microSD image (u-boot, kernel, OS config, etc.)

Phil P.

2

Where did you purchase these boards from?

Gerald

3

does it also happen if no cape is attached? if it works correctly then, make sure you do not connect any pullup/down to the bootconfig pins of the cpu - this may cause the observed behaviour.

regards

cornelius

4

Check the pulls on SYSBOOT[15:14]. You can also dump the latched
values for these @ 0x44e10040
from U-Boot or kernel.

5

Don’t remember exactly. Either Mouser or Element14. I’ve gotten equivalent quotes from both.

6

Danke,

I can’t test without the cape as the other hardware the application needs is on the cape.

However this suggestion together with what Vaibhav pointed to, seems to be the issue.

My cape also uses the UART5 signals. Probably a bad idea given that TX/RX and CTS/RTS for that port are all used in the boot config… ARGH…

I unplugged the serial cable on UART5, did a hard power cycle and it boots with 24MHz and the TSC works now.

Is there any way to override or rewrite the SYS_BOOT config in uboot before we boot the OS?

If I dig through the chip manual, can I come up with the right sequence of memory pokes to reprogram the timers before booting the OS in u-boot?

I tried the reset button with the UART5 unplugged but it continues to boot with 19.2MHz not 24MHz. The only way to reset the SYS_BOOT seems to be a hard power cycle. Is that correct?

PS. I’ve seen a few other people having problems with the touch screen controller ADC driver due to this same problem on the TI message boards. It’s not obvious to people why the driver doesn’t load. And the TSC driver OOPS’s with a NULL pointer exception in kernel space when it doesn’t initialize correctly.

Thanks!

7

it seems to me if you need to use any of the pins that control the boot
you put a buffer between your devices/ICs and the boot pins to isolate
during boot then enable the buffers and everything should be happy.

8

Hmm ... a couple of ugly hacks that you can try out...
1. The bits assigned to SYSBOOT[15:14] in CONTROL_STATUS are marked r/w
in the TRM so you could in theory modify those to 0x01 from U-Boot.
Kernel would then
get the right value from the register.
2. Another hack would be to modify the kernel clock data to interpret
0x00 as 24MHz
(look at the clock file for am33xx under arch/arm/mach-omap2)

Of course, the right fix would be to place a buffer to ensure the
right values are latched
and you don't need any s/w hacks.

Regards,
Vaibhav

9

having a buffer would be a cleaner solution, but you can also try to add a
"stronger" pull up/down, the pull up/down on the BB are just 42.2K/100K. I had
success once using a 4.7K (or maybe even lower) on one of the uart5 lines. but
make sure you are not drawing too much current from the port.

10

Buffer is the way to go. Do not drive these pins during power up. You may want to check the System Reference Manual.

Gerald