Continuing UCC UART woes

Continuing UCC UART woes

[Gary Thomas]

I thought I had this working, but it seems to only work for UCC3.
Sadly, I can't get it to work on UCC4/UCC5/UCC8 at all.

Starting with UCC4, I have:
             /* ttyQE0 (UCC4) */
             serial_qe0: serial@3200 {
                 device_type = "serial";
                 compatible = "ucc_uart";
                 cell-index = <4>;
                 reg = <0x3200 0x200>;
                 interrupts = <35>;
                 interrupt-parent = <&qeic>;
                 port-number = <0>;
                 rx-clock-name = "brg9";
                 tx-clock-name = "brg10";
                 soft-uart;
             };

With this setup, I can receive characters from the device, but
no characters ever go out.  Same behaviour as before - the output
descriptors get filled, but no action seems to be taken, no interrupts,
etc.  Except randomly there will be output!  For example, if I
connect to the port with minicom, what I type is received by /dev/ttyQE2.
On some rare occasions, what I type is also echoed back, but when
this happens, it's only the first couple of characters, then nothing.

I verified that the CMXUCR registers are being set per the DTS
as well as the BRG registers.  They all look correct:

   ucc_set_qe_mux_rxtx - CMX: 0x000a0000

   root@ppc_target:~ stty </dev/ttyQE0 38400
   qe_setbrg - BRG: fddfd660 = 0x000106b6, CLK = 132000000, RATE = 9600, MULTIPLIER = 16
   qe_setbrg - BRG: fddfd664 = 0x000106b5, CLK = 132000000, RATE = 9600, MULTIPLIER = 1
   qe_setbrg - BRG: fddfd660 = 0x000101aa, CLK = 132000000, RATE = 38400, MULTIPLIER = 16
   qe_setbrg - BRG: fddfd664 = 0x00011ada, CLK = 132000000, RATE = 38400, MULTIPLIER = 1

I've also tried this on UCC5 & UCC8 which show the identical
behaviour - input works, output does not.  I've tried running
with only a single soft UART (UCC4) as well as having all three
configured.  No changes seen.

At this point, I'm using the stock driver from 2.6.33.3

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@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?

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Continuing UCC UART woes

[Gary Thomas]

On 06/24/2010 06:54 AM, Gary Thomas wrote:
> I thought I had this working, but it seems to only work for UCC3.
> Sadly, I can't get it to work on UCC4/UCC5/UCC8 at all.
>
> Starting with UCC4, I have:
> /* ttyQE0 (UCC4) */
> serial_qe0: serial@3200 {
> device_type = "serial";
> compatible = "ucc_uart";
> cell-index = <4>;
> reg = <0x3200 0x200>;
> interrupts = <35>;
> interrupt-parent = <&qeic>;
> port-number = <0>;
> rx-clock-name = "brg9";
> tx-clock-name = "brg10";
> soft-uart;
> };
>
> With this setup, I can receive characters from the device, but
> no characters ever go out. Same behaviour as before - the output
> descriptors get filled, but no action seems to be taken, no interrupts,
> etc. Except randomly there will be output! For example, if I
> connect to the port with minicom, what I type is received by /dev/ttyQE2.
> On some rare occasions, what I type is also echoed back, but when
> this happens, it's only the first couple of characters, then nothing.
>
> I verified that the CMXUCR registers are being set per the DTS
> as well as the BRG registers. They all look correct:
>
> ucc_set_qe_mux_rxtx - CMX: 0x000a0000
>
> root@ppc_target:~ stty </dev/ttyQE0 38400
> qe_setbrg - BRG: fddfd660 = 0x000106b6, CLK = 132000000, RATE = 9600,
> MULTIPLIER = 16
> qe_setbrg - BRG: fddfd664 = 0x000106b5, CLK = 132000000, RATE = 9600,
> MULTIPLIER = 1
> qe_setbrg - BRG: fddfd660 = 0x000101aa, CLK = 132000000, RATE = 38400,
> MULTIPLIER = 16
> qe_setbrg - BRG: fddfd664 = 0x00011ada, CLK = 132000000, RATE = 38400,
> MULTIPLIER = 1
>
> I've also tried this on UCC5 & UCC8 which show the identical
> behaviour - input works, output does not. I've tried running
> with only a single soft UART (UCC4) as well as having all three
> configured. No changes seen.
>
> At this point, I'm using the stock driver from 2.6.33.3
>
> 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@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?

BTW, I tried converting the  Soft_UART_mpc8360_r2.1.h file
to the firmware format.  I had to fiddle with the conversion
program a bit because the firmware has version 0.1.2, but I
ended up with a new firmware file.  Here's the change I made:

$ diff -u make_qe_firmware.py*
--- make_qe_firmware.py 2010-06-24 07:19:31.000000000 -0600
+++ make_qe_firmware.py~        2010-06-24 07:15:54.000000000 -0600
@@ -260,7 +260,7 @@
      print "Unknown SOC model\n"
      exit(1)

-if not ucode_major and not ucode_minor:
+if not ucode_major:
      print "Unknown microcode version\n"
      exit(1)



No change in behaviour :-(


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Continuing UCC UART woes

[Chuck Meade]

> 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@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

Re: Continuing UCC UART woes

[Gary Thomas]

On 06/24/2010 07:38 AM, Chuck Meade wrote:
>> 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@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.

As reported, I've done this - no change.

>
> 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.

I've also done this - the descriptors are set up, never touched by the QE
Odd that input always works, output works only very rarely.

> 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.

No change whether these pins are configured or not.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Continuing UCC UART woes

[Chuck Meade]

>> 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.
> 
> I've also done this - the descriptors are set up, never touched by the QE
> Odd that input always works, output works only very rarely.

You could check alignment of the BD address to be sure that got setup correctly.
Make sure you are not looking at a cached version of the BD, and make sure
you waited long enough for the QE to have processed it.

>> 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.
> 
> No change whether these pins are configured or not.

I would definitely leave these configured as GPIOs if the correct signals
are not present at the pins.

You could look through the pdf that is in that zipfile and make sure you are
following (that the driver is following) all the restrictions for soft UART
mode.

Perhaps printk debug in ucc_slow_init to make sure the UCC is getting set up correctly.
I would probably also make sure that the Tx parameter ram is allocated and
aligned OK.

Make sure you specify unique port-number fields in your dts for each of these UCC UARTs.

Beyond that, if printk-debugging does not show anything, then you may want to contact
Freescale and try to find out what the Soft UART mode microcode patch capabilities are,
in terms of exactly how many simultaneous UCC UARTs it has been proven to support.
The QE has processing limits, and maybe the soft UART microcode patch can't support
multiple UCC UARTs(?)  It's worth it to find out from Freescale I suppose.

Chuck Meade
chuck@ThePTRGroup.com