Continuing UCC UART woes

Chuck Meade chuck at ThePTRGroup.com
Thu Jun 24 23:38:24 EST 2010


> One thing I noticed is that the firmware patch seems quite old.
> I got the firmware package from http://opensource.freescale.com/firmware/
> We were also told (by FreeScale) to look at
> https://www.freescale.com/webapp/Download?colCode=QERAMPKG
> 
> Looking at these two packages, it's unclear that they match.  Certainly
> the dates are very different:
> 
> [gthomas at hermes 8358]$ ls -l fsl_qe_ucode QERAMPKG
> fsl_qe_ucode:
> total 16
> -rw-rw-r-- 1 gthomas gthomas 5940 2007-12-10 14:39
> fsl_qe_ucode_uart_8360_21.bin
> -rw-r--r-- 1 gthomas gthomas 7892 2007-11-30 10:14 license.txt
> 
> QERAMPKG:
> total 972
> -rw-rw-r-- 1 gthomas gthomas 132915 2009-04-07 14:04
> SlowProtocols_8323rev11.c
> -rw-rw-r-- 1 gthomas gthomas 455446 2009-09-16 15:44
> Soft_UART_Microcode_Rel_0_1_2.pdf
> -rw-rw-r-- 1 gthomas gthomas  29379 2009-09-16 15:49
> Soft_UART_mpc8360_r2.0.h
> -rw-rw-r-- 1 gthomas gthomas  29379 2009-09-16 15:14
> Soft_UART_mpc8360_r2.1.h
> -rw-rw-r-- 1 gthomas gthomas  29379 2009-09-16 15:14
> Soft_UART_mpc8568_r1.1.h
> -rw-rw-r-- 1 gthomas gthomas 105457 2009-09-16 16:00 SWUART_8360rev20.c
> -rw-rw-r-- 1 gthomas gthomas  34689 2009-09-16 15:32 SWUART_8360rev20.srx
> -rw-rw-r-- 1 gthomas gthomas 105318 2009-09-16 15:59 SWUART_8360rev21.c
> -rw-rw-r-- 1 gthomas gthomas  34689 2009-09-16 15:14 SWUART_8360rev21.srx
> 
> Any ideas what I'm doing wrong?

Hi Gary,

At http://opensource.freescale.com/firmware there is a script make_qe_firmware.py
that Timur said would create a firmware binary out of the firmware header file.
I have not used this script, since the existing binary worked for me.
But I am using only one UCC UART, so you are going beyond what I have done
with this firmware.

You can try to use that script to create a newer firmware binary from the header
in that zip file.  Make sure you are using the right one for your silicon rev.

You can use strategic printk debugging in the ucc_uart.c driver to determine
on the Tx side what is going wrong.  For example, after you tell the QE to
output chars, wait a bit and printk out the BD.  See if the QE is clearing the
READY bit in that BD.  That will tell you if the QE is even processing the BD
or not.

Also ensure that for all these other UCCs that you are using that the CD, CTS,
RTS pins are set up as plain GPIO pins if you do not have them hooked up to
actual CD, CTS, RTS signals.  If you *are* using HW flow control, probe all the
signals to be sure they are all correct.

Chuck



More information about the Linuxppc-dev mailing list