On 06/22/2010 01:01 PM, Chuck Meade wrote:
What BRGs did you choose for tx and rx?
BRG1& BRG2
OK
Get a scope on the UCC3 tx pin and try to output some chars. See if
there is
any digital activity on that pin at all. If you are looking at a
terminal for
output, there are too many things that could be wrong between that tx
pin and
your display (e.g. level translation issue, null modem issue, baud
incompatibility,
terminal program set for XON/XOFF or HW flow control and UART not set
up compatibly).
For now get the probe directly on the CPU's UCC3 Tx pin, output chars
and see
if there is any activity.
We've done all this - nothing on the pins directly at the CPU.
This is behaving very much like there is no clock to the device.
Is there something special that needs to be done to get the BRGs
to work?
If I was doing this, at this point I would do some strategic printk debugging
within ucc_uart.c. You said that you are using 2.6.33.3, so you already have
all the fixes in ucc_slow.c that I had to backport to my older kernel.
If you question the setup of the BRGs, go to your function that sets them up.
I don't know about 2.6.33.3, but in the latest kernel it is qe_setbrg() in
qe.c. At the very bottom there is an out_be32().
printk both the address, and the value that is being written to that address.
You may need to cast the values to unsigned longs to printk them. I will look
at your numbers if you send them to me. In my implemenation (which again was
a backport, so this may not apply to you) the BRG writes were off by 4 bytes.
But I think that this error was due to the backport -- a logic mismatch I
needed to resolve during the port.
Also in the current Linux kernel, there is a dependence on the correctness
of the "brg-frequency" property from the dts. Look up above qe_setbrg() at
the qe_get_brg_clk() function. Before the return (there are multiple return
points) printk the brg_clk being returned. That must be correct for your
hardware -- must be the actual brg freq. I assume that you are booting from
U-Boot. I believe in modern implementations that U-Boot fills in the
brg-frequency in the device tree at boot time.
The driver claims to work with either bus-frequency or brg-frequency set.
I only had bus-frequency; when I set brg-frequency, it has started to work.
Now to test it with a scope to see what else is wrong...
BTW, I use RedBoot - being the original author, how could I not?
Thanks for the help
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
