UCC UART

UCC UART

[Gary Thomas]

I'm still trying to get UCC UART to work on my MPC8358 with
the 2.6.33.3 kernel.

When I try to send data to the port, there is no output, not
even any interrupts on the device.  What I see is that the UART
driver seems to initialize fine and pushes characters into
the output buffers & descriptors.  However, there are no
interrupts hence it just sits there...

My device tree entry for this device now looks like this:
	/* ttyQE0 (UCC3) */
	serial_qe0: serial@4000 {
                 device_type = "serial";
                 compatible = "ucc_uart";
                 cell-index = <3>;
		reg = <0x2200 0x200>;
		interrupts = <34>;
		interrupt-parent = <&qeic>;
                 port-number = <0>;
		rx-clock-name = "brg1";
		tx-clock-name = "brg1";
	};

* Are there any known issues with this driver?
* Is there any way to get a handle on why no data is moving?
* Is there some way to tell if the QE even sees the descriptors?
* The driver and documentation mention a "soft UART" mode for
   chips with broken UART hardware.  How do I know if my board
   has functioning UART hardware?

Note: I have UCC1+UCC2 working great with ethernet.

Thanks for any pointers or ideas

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

Re: UCC UART

[Tabi Timur-B04825]

[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]

Gary Thomas wrote:
> I'm still trying to get UCC UART to work on my MPC8358 with
> the 2.6.33.3 kernel.
>
> When I try to send data to the port, there is no output, not
> even any interrupts on the device. What I see is that the UART
> driver seems to initialize fine and pushes characters into
> the output buffers & descriptors. However, there are no
> interrupts hence it just sits there...
>
> My device tree entry for this device now looks like this:
> /* ttyQE0 (UCC3) */
> serial_qe0: serial@4000 {
> device_type = "serial";
> compatible = "ucc_uart";
> cell-index = <3>;
> reg = <0x2200 0x200>;
> interrupts = <34>;
> interrupt-parent = <&qeic>;
> port-number = <0>;
> rx-clock-name = "brg1";
> tx-clock-name = "brg1";
> };

You might try assigning different BRGs to TX and RX.

>
> * Are there any known issues with this driver?

Heh. :-)

I'd say that there are plenty of unknown issues with this driver/hardware. 
For some reason, QE UART is just unreliable.  I've had several people try to 
use the QE for UART, and almost everyone has problems with it.

> * Is there any way to get a handle on why no data is moving?

The QE is a black box.  If you're programming it correctly but it doesn't do 
what it's supposed to, there's almost no way to debug it.

> * Is there some way to tell if the QE even sees the descriptors?

Not to my knowledge.

> * The driver and documentation mention a "soft UART" mode for
> chips with broken UART hardware. How do I know if my board
> has functioning UART hardware?

I believe only the 8323 and the 8360 have broken UARTs.  Those are the only 
ones that have the microcode update that enable soft-UART, anyway.

>
> Note: I have UCC1+UCC2 working great with ethernet.
>
> Thanks for any pointers or ideas

You should contact Freescale support and ask them for help.  Even though I 
wrote the Linux driver, I have no "inside" connection to the QE team here at 
Freescale.

[-- Attachment #2: Type: text/html, Size: 2782 bytes --]

Re: UCC UART

[Chuck Meade]

On 06/22/2010 10:55 AM, Gary Thomas wrote:
> I'm still trying to get UCC UART to work on my MPC8358 with
> the 2.6.33.3 kernel.
> 
> When I try to send data to the port, there is no output, not
> even any interrupts on the device.  What I see is that the UART
> driver seems to initialize fine and pushes characters into
> the output buffers & descriptors.  However, there are no
> interrupts hence it just sits there...
> 
> My device tree entry for this device now looks like this:
>     /* ttyQE0 (UCC3) */
>     serial_qe0: serial@4000 {
>                 device_type = "serial";
>                 compatible = "ucc_uart";
>                 cell-index = <3>;
>         reg = <0x2200 0x200>;
>         interrupts = <34>;
>         interrupt-parent = <&qeic>;
>                 port-number = <0>;
>         rx-clock-name = "brg1";
>         tx-clock-name = "brg1";
>     };
> 
> * Are there any known issues with this driver?
> * Is there any way to get a handle on why no data is moving?
> * Is there some way to tell if the QE even sees the descriptors?
> * The driver and documentation mention a "soft UART" mode for
>   chips with broken UART hardware.  How do I know if my board
>   has functioning UART hardware?
> 
> Note: I have UCC1+UCC2 working great with ethernet.
> 
> Thanks for any pointers or ideas

Hi Gary,

According to the errata, it looks like the MPC8358 is subject to
erratum QE_UART6.  You'll need to use soft UART mode and load the
microcode patch.  Once that is done you will also need to use two
different BRG's, one for tx and one for rx, since the soft UART mode
microcode patch requires them to be set to different rates (I believe
Rx is 16*baud under soft UART mode, and Tx is 1*baud).

Also, I don't know if it matters or not, but you should change your
dts entry "serial@4000" to "serial@2200", just like you recently changed
your "reg =" to 0x2200.

Chuck Meade
chuck@ThePTRGroup.com

Re: UCC UART

[Gary Thomas]

On 06/22/2010 09:10 AM, Chuck Meade wrote:
> On 06/22/2010 10:55 AM, Gary Thomas wrote:
>> I'm still trying to get UCC UART to work on my MPC8358 with
>> the 2.6.33.3 kernel.
>>
>> When I try to send data to the port, there is no output, not
>> even any interrupts on the device.  What I see is that the UART
>> driver seems to initialize fine and pushes characters into
>> the output buffers&  descriptors.  However, there are no
>> interrupts hence it just sits there...
>>
>> My device tree entry for this device now looks like this:
>>      /* ttyQE0 (UCC3) */
>>      serial_qe0: serial@4000 {
>>                  device_type = "serial";
>>                  compatible = "ucc_uart";
>>                  cell-index =<3>;
>>          reg =<0x2200 0x200>;
>>          interrupts =<34>;
>>          interrupt-parent =<&qeic>;
>>                  port-number =<0>;
>>          rx-clock-name = "brg1";
>>          tx-clock-name = "brg1";
>>      };
>>
>> * Are there any known issues with this driver?
>> * Is there any way to get a handle on why no data is moving?
>> * Is there some way to tell if the QE even sees the descriptors?
>> * The driver and documentation mention a "soft UART" mode for
>>    chips with broken UART hardware.  How do I know if my board
>>    has functioning UART hardware?
>>
>> Note: I have UCC1+UCC2 working great with ethernet.
>>
>> Thanks for any pointers or ideas
>
> Hi Gary,
>
> According to the errata, it looks like the MPC8358 is subject to
> erratum QE_UART6.  You'll need to use soft UART mode and load the
> microcode patch.  Once that is done you will also need to use two
> different BRG's, one for tx and one for rx, since the soft UART mode
> microcode patch requires them to be set to different rates (I believe
> Rx is 16*baud under soft UART mode, and Tx is 1*baud).

As I feared!  Can you tell me where/how to get the microcode patch?

> Also, I don't know if it matters or not, but you should change your
> dts entry "serial@4000" to "serial@2200", just like you recently changed
> your "reg =" to 0x2200.

I did that as soon as I sent this and saw the glaring inconsistency :-)

Thanks

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

Re: UCC UART

[Chuck Meade]

>> Hi Gary,
>>
>> According to the errata, it looks like the MPC8358 is subject to
>> erratum QE_UART6.  You'll need to use soft UART mode and load the
>> microcode patch.  Once that is done you will also need to use two
>> different BRG's, one for tx and one for rx, since the soft UART mode
>> microcode patch requires them to be set to different rates (I believe
>> Rx is 16*baud under soft UART mode, and Tx is 1*baud).
> 
> As I feared!  Can you tell me where/how to get the microcode patch?
> 
>> Also, I don't know if it matters or not, but you should change your
>> dts entry "serial@4000" to "serial@2200", just like you recently changed
>> your "reg =" to 0x2200.
> 
> I did that as soon as I sent this and saw the glaring inconsistency :-)
> 
> Thanks

Sure.  Go to opensource.freescale.com/firmware and download (for your MPC8358)
the 8360 soft UART mode microcode patch.  You will need to know if your CPU
is a 2.0 or 2.1 silicon, since there is a different microcode patch for each.

Then in the kernel config I believe I included CONFIG_FW_LOADER and CONFIG_HOTPLUG
(one of those may have autoselected the other).

Make sure in your ucc_uart.c driver that soft uart mode is enabled.

At boot time, the driver will kick off a 10 second timer that will expect
the microcode patch to be loaded before the end of that 10 secs.

Very early in my boot sequence, I have a startup script send the microcode patch
file to the driver through the firmware-loading sysfs entry.  But you need to
be aware that the UCC number in the sysfs path will be offset by one.  Since you
are using UCC3, you should use a '2' in the path as shown below.  This sequence
worked for me (I changed the number for you to '2' in my command sequence, since
I use a different UCC):

  echo 1 > /sys/class/firmware/fsl-ucc-uart2/loading
  cat /root/fsl_qe_ucode_uart_8360_21.bin > /sys/class/firmware/fsl-ucc-uart2/data
  echo 0 > /sys/class/firmware/fsl-ucc-uart2/loading

Note that the above presupposes you are using the file for silicon 2.1.
Also presupposes that you have put the microcode under your rootfs /root directory.

Chuck Meade
chuck@ThePTRGroup.com

Re: UCC UART

[Gary Thomas]

On 06/22/2010 09:28 AM, Chuck Meade wrote:
>>> Hi Gary,
>>>
>>> According to the errata, it looks like the MPC8358 is subject to
>>> erratum QE_UART6.  You'll need to use soft UART mode and load the
>>> microcode patch.  Once that is done you will also need to use two
>>> different BRG's, one for tx and one for rx, since the soft UART mode
>>> microcode patch requires them to be set to different rates (I believe
>>> Rx is 16*baud under soft UART mode, and Tx is 1*baud).
>>
>> As I feared!  Can you tell me where/how to get the microcode patch?
>>
>>> Also, I don't know if it matters or not, but you should change your
>>> dts entry "serial@4000" to "serial@2200", just like you recently changed
>>> your "reg =" to 0x2200.
>>
>> I did that as soon as I sent this and saw the glaring inconsistency :-)
>>
>> Thanks
>
> Sure.  Go to opensource.freescale.com/firmware and download (for your MPC8358)
> the 8360 soft UART mode microcode patch.  You will need to know if your CPU
> is a 2.0 or 2.1 silicon, since there is a different microcode patch for each.
>
> Then in the kernel config I believe I included CONFIG_FW_LOADER and CONFIG_HOTPLUG
> (one of those may have autoselected the other).
>
> Make sure in your ucc_uart.c driver that soft uart mode is enabled.
>
> At boot time, the driver will kick off a 10 second timer that will expect
> the microcode patch to be loaded before the end of that 10 secs.
>
> Very early in my boot sequence, I have a startup script send the microcode patch
> file to the driver through the firmware-loading sysfs entry.  But you need to
> be aware that the UCC number in the sysfs path will be offset by one.  Since you
> are using UCC3, you should use a '2' in the path as shown below.  This sequence
> worked for me (I changed the number for you to '2' in my command sequence, since
> I use a different UCC):
>
>    echo 1>  /sys/class/firmware/fsl-ucc-uart2/loading
>    cat /root/fsl_qe_ucode_uart_8360_21.bin>  /sys/class/firmware/fsl-ucc-uart2/data
>    echo 0>  /sys/class/firmware/fsl-ucc-uart2/loading
>
> Note that the above presupposes you are using the file for silicon 2.1.
> Also presupposes that you have put the microcode under your rootfs /root directory.

Thanks, I'll give this a try.  When I download the firmware this way,
do I need to follow the directions in
   Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt

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

Re: UCC UART

[Chuck Meade]

>> Sure.  Go to opensource.freescale.com/firmware and download (for your
>> MPC8358)
>> the 8360 soft UART mode microcode patch.  You will need to know if
>> your CPU
>> is a 2.0 or 2.1 silicon, since there is a different microcode patch
>> for each.
>>
>> Then in the kernel config I believe I included CONFIG_FW_LOADER and
>> CONFIG_HOTPLUG
>> (one of those may have autoselected the other).
>>
>> Make sure in your ucc_uart.c driver that soft uart mode is enabled.
>>
>> At boot time, the driver will kick off a 10 second timer that will expect
>> the microcode patch to be loaded before the end of that 10 secs.
>>
>> Very early in my boot sequence, I have a startup script send the
>> microcode patch
>> file to the driver through the firmware-loading sysfs entry.  But you
>> need to
>> be aware that the UCC number in the sysfs path will be offset by one. 
>> Since you
>> are using UCC3, you should use a '2' in the path as shown below.  This
>> sequence
>> worked for me (I changed the number for you to '2' in my command
>> sequence, since
>> I use a different UCC):
>>
>>    echo 1>  /sys/class/firmware/fsl-ucc-uart2/loading
>>    cat /root/fsl_qe_ucode_uart_8360_21.bin> 
>> /sys/class/firmware/fsl-ucc-uart2/data
>>    echo 0>  /sys/class/firmware/fsl-ucc-uart2/loading
>>
>> Note that the above presupposes you are using the file for silicon 2.1.
>> Also presupposes that you have put the microcode under your rootfs
>> /root directory.
> 
> Thanks, I'll give this a try.  When I download the firmware this way,
> do I need to follow the directions in
>   Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt

I did not do that, and I have it running here.  I will say though that I
hardcoded the driver to run in soft UART mode.  You will need to at least
add the appropriate line to your dts to get the driver to operate in
Soft UART mode.

I hardcoded mine because I had to backport this UCC UART driver to an older
Linux kernel, and that kernel was from before dts existed.

Add whatever you need to your dts to make it run in soft UART mode and get
the firmware loaded.  Use two different BRGs for tx and rx.  Make sure your
BRG choice is valid for your UCC3.

I believe that the UCC UART support has not had too much use so far, but
I do have it working (in that older kernel after backporting).

Chuck Meade
chuck@ThePTRGroup.com

Re: UCC UART

[Gary Thomas]

On 06/22/2010 09:53 AM, Chuck Meade wrote:
>>> Sure.  Go to opensource.freescale.com/firmware and download (for your
>>> MPC8358)
>>> the 8360 soft UART mode microcode patch.  You will need to know if
>>> your CPU
>>> is a 2.0 or 2.1 silicon, since there is a different microcode patch
>>> for each.
>>>
>>> Then in the kernel config I believe I included CONFIG_FW_LOADER and
>>> CONFIG_HOTPLUG
>>> (one of those may have autoselected the other).
>>>
>>> Make sure in your ucc_uart.c driver that soft uart mode is enabled.
>>>
>>> At boot time, the driver will kick off a 10 second timer that will expect
>>> the microcode patch to be loaded before the end of that 10 secs.
>>>
>>> Very early in my boot sequence, I have a startup script send the
>>> microcode patch
>>> file to the driver through the firmware-loading sysfs entry.  But you
>>> need to
>>> be aware that the UCC number in the sysfs path will be offset by one.
>>> Since you
>>> are using UCC3, you should use a '2' in the path as shown below.  This
>>> sequence
>>> worked for me (I changed the number for you to '2' in my command
>>> sequence, since
>>> I use a different UCC):
>>>
>>>     echo 1>   /sys/class/firmware/fsl-ucc-uart2/loading
>>>     cat /root/fsl_qe_ucode_uart_8360_21.bin>
>>> /sys/class/firmware/fsl-ucc-uart2/data
>>>     echo 0>   /sys/class/firmware/fsl-ucc-uart2/loading
>>>
>>> Note that the above presupposes you are using the file for silicon 2.1.
>>> Also presupposes that you have put the microcode under your rootfs
>>> /root directory.
>>
>> Thanks, I'll give this a try.  When I download the firmware this way,
>> do I need to follow the directions in
>>    Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt
>
> I did not do that, and I have it running here.  I will say though that I
> hardcoded the driver to run in soft UART mode.  You will need to at least
> add the appropriate line to your dts to get the driver to operate in
> Soft UART mode.
>
> I hardcoded mine because I had to backport this UCC UART driver to an older
> Linux kernel, and that kernel was from before dts existed.
>
> Add whatever you need to your dts to make it run in soft UART mode and get
> the firmware loaded.  Use two different BRGs for tx and rx.  Make sure your
> BRG choice is valid for your UCC3.
>
> I believe that the UCC UART support has not had too much use so far, but
> I do have it working (in that older kernel after backporting).

I've done all this but sadly the behaviour is the same :-(

Any ideas what I might be missing?

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

Re: UCC UART

[Chuck Meade]

>> I did not do that, and I have it running here.  I will say though that I
>> hardcoded the driver to run in soft UART mode.  You will need to at least
>> add the appropriate line to your dts to get the driver to operate in
>> Soft UART mode.
>>
>> I hardcoded mine because I had to backport this UCC UART driver to an
>> older
>> Linux kernel, and that kernel was from before dts existed.
>>
>> Add whatever you need to your dts to make it run in soft UART mode and
>> get
>> the firmware loaded.  Use two different BRGs for tx and rx.  Make sure
>> your
>> BRG choice is valid for your UCC3.
>>
>> I believe that the UCC UART support has not had too much use so far, but
>> I do have it working (in that older kernel after backporting).
> 
> I've done all this but sadly the behaviour is the same :-(
> 
> Any ideas what I might be missing?

Check your setup of the UCC3 pins for UART mode.  Make sure you either have
the UCC3 CD, CTS, RTS pins at the correct levels, or deconfigure those pins
(set them up as GPIOs).  Just verify every pin is properly set up for UCC3.
The UCC3 TxD and RxD signals must be set up properly.

What BRGs did you choose for tx and rx?

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.

Chuck Meade
chuck@ThePTRGroup.com

Re: UCC UART

[Gary Thomas]

On 06/22/2010 12:14 PM, Chuck Meade wrote:
>>> I did not do that, and I have it running here.  I will say though that I
>>> hardcoded the driver to run in soft UART mode.  You will need to at least
>>> add the appropriate line to your dts to get the driver to operate in
>>> Soft UART mode.
>>>
>>> I hardcoded mine because I had to backport this UCC UART driver to an
>>> older
>>> Linux kernel, and that kernel was from before dts existed.
>>>
>>> Add whatever you need to your dts to make it run in soft UART mode and
>>> get
>>> the firmware loaded.  Use two different BRGs for tx and rx.  Make sure
>>> your
>>> BRG choice is valid for your UCC3.
>>>
>>> I believe that the UCC UART support has not had too much use so far, but
>>> I do have it working (in that older kernel after backporting).
>>
>> I've done all this but sadly the behaviour is the same :-(
>>
>> Any ideas what I might be missing?
>
> Check your setup of the UCC3 pins for UART mode.  Make sure you either have
> the UCC3 CD, CTS, RTS pins at the correct levels, or deconfigure those pins
> (set them up as GPIOs).  Just verify every pin is properly set up for UCC3.
> The UCC3 TxD and RxD signals must be set up properly.

Only UCC3 RxD and TxD are configured

> What BRGs did you choose for tx and rx?

BRG1 & BRG2

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

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

Re: UCC UART

[Chuck Meade]

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

Re: UCC UART

[Gary Thomas]

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

Re: UCC UART

[Chuck Meade]

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

No problem -- I am glad it is working for you now.

Chuck Meade
chuck@ThePTRGroup.com

Re: UCC UART

[Timur Tabi]

Timur Tabi wrote:
> I'd say that there are plenty of unknown issues with this driver/hardware. 
> For some reason, QE UART is just unreliable.  I've had several people try to 
> use the QE for UART, and almost everyone has problems with it.

I finally got in touch with one of the other development teams, and they
said that they got QE UART working with the 8569 and the P1021.  The
reference board we make with the 8568 does not have QE pinned to the UART,
so they didn't try to support that.

Re: UCC UART

[Gary Thomas]

On 06/24/2010 03:20 PM, Timur Tabi wrote:
> Timur Tabi wrote:
>> I'd say that there are plenty of unknown issues with this driver/hardware.
>> For some reason, QE UART is just unreliable.  I've had several people try to
>> use the QE for UART, and almost everyone has problems with it.
>
> I finally got in touch with one of the other development teams, and they
> said that they got QE UART working with the 8569 and the P1021.  The
> reference board we make with the 8568 does not have QE pinned to the UART,
> so they didn't try to support that.

What about 8358?  I'm really stuck here - Rx seems to work,
but Tx is totally dead...

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