This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Async3 cannot switch to PLL1?

Other Parts Discussed in Thread: OMAP-L138

I have already posted a message to the Arago email list with more detail, but I think this problem is more hardware related than software.

I am using Arago Linux  v2.6.37_DAVINCIPSP_03.21.00.04  on an OMAP-L138.  By adding a bunch of print statements and debug code, and observing the baud rate of the serial terminal (UART2), it appears that ASYNC3 cannot source from PLL1 SYSCLK/2. Rather, the register CFGCHIP3 updates properly when written to make a change over to PLL1, but the baud rate of the serial terminal reflects the rate of PLL0.

Some details of my setup:

20 MHz oscillator

UBL setup as follows:

status |= DEVICE_PLL0Init(0, 19, 0, 0, 0, 31, 7);
status |= DEVICE_PLL1Init(14, 0, 0, 1, 5);

PLL0 outputs at:
SYSCLK1 - 400 MHz
SYSCLK2 - 200 MHz
SYSCLK3 - 12.5 MHz
SYSCLK7 - 50MHz
and PLL1:
SYSCLK1 - 300 MHz
SYSCLK2 - 150 MHz
SYSCLK3 - 50 MHz

In linux I changed the "OPP" to reflect these settings, and made other necessary changes to make sure the kernel keeps these PLL settings..

When switching ASYNC3 to PLL1, the baud rate of UART2 reflects an ASYNC3 input of 200MHz. The measured baud rate is 154000, the UART divider is 81. This is all verified with print statements.

One peculiar thing I noticed from TI's clocking spreadsheet is that 200MHz is not a permissible value for ASYNC3. I don't know if that would somehow prevent the hardware from switching from the 200MHz PLL0 clock to the 150MHz PLL1 clock source.

Thanks

- Judson

  • Further investigation indicates some of my assumptions might be incorrect.

    If I change ASYNC3 source to PLL1 from within UBL, and change the UART div to 81, I get proper 115K baud rate from UBL.

    U-Boot then has the wrong baud rate - but I am betting it is not smart enough to check the source of ASYNC3.

    At this point I am pretty sure ASYNC3 points to PLL1.

    The kernel then still has the 154k baud rate. My print statements show that the ASYNC3_SOURCE bit in CFGCHIP3 is 1 both before and after the code tries to set it to PLL1.

    This kind of has me baffled.  The UART is being sourced from 200MHz, but ASYNC3 is sourced from PLL1 which is 150MHz, and at least one check of the multiplier in adjacent code shows that its multiplier is 15 (and note, the DDR ram is working). These cannot both be true.

  • Sorry, some of our in-house modifications were reverting the ASYNC3 back to PLL0, improperly (in a way that the clock source software would never see), and it was happening after all my print statements so I couldn't see it.

    Problem Solved.