From: Chuck Meade <chuck@ThePTRGroup•com>
To: linuxppc-dev@lists•ozlabs.org
Subject: Re: UCC UART
Date: Tue, 22 Jun 2010 15:01:38 -0400 [thread overview]
Message-ID: <4C210892.3040503@ThePTRGroup.com> (raw)
In-Reply-To: <4C2103DE.6020801@mlbassoc.com>
>> 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.
Let me know how it goes,
Chuck Meade
chuck@ThePTRGroup•com
next prev parent reply other threads:[~2010-06-22 19:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-22 14:55 UCC UART Gary Thomas
2010-06-22 15:06 ` Tabi Timur-B04825
2010-06-22 15:10 ` Chuck Meade
2010-06-22 15:14 ` Gary Thomas
2010-06-22 15:28 ` Chuck Meade
2010-06-22 15:46 ` Gary Thomas
2010-06-22 15:53 ` Chuck Meade
2010-06-22 17:44 ` Gary Thomas
2010-06-22 18:14 ` Chuck Meade
2010-06-22 18:41 ` Gary Thomas
2010-06-22 19:01 ` Chuck Meade [this message]
2010-06-22 21:19 ` Gary Thomas
2010-06-22 21:27 ` Chuck Meade
[not found] ` <4C20D162.2020302@freescale.com>
2010-06-24 21:20 ` Timur Tabi
2010-06-25 0:49 ` Gary Thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C210892.3040503@ThePTRGroup.com \
--to=chuck@theptrgroup$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox