Re: 8xx SCC's as uart

Re: 8xx SCC's as uart

[Steven Scholz]

Eli Brin wrote:
> Hello,
>
> I have noticed, in kernel 2.4.20, that SCC1 and SCC4 cannot be configured as
> uarts.
>
> Also, the configuration for RTS,CTS,DCD and DTR are missing.
>
> Comparing 8xx_io/uart.c file to the 2.4.4 version of uart.c shows that all
> the code to support the above has been removed, although both show driver
> 0.3.
>
> Our target will use all SCC's as uarts with hardware handshake. So I will
> need to put this back into uart.c and the config.in files.
>
> Is there a reason for this feature (SCC1 and SCC4 as uarts are part of the
> 8xx ability) being removed ?

They haven't been removed! This feature just never made it into the
official BitKeeper tree.

Have a look at linuxppc_2_4_devel in the DENX CVS. Especialy between
the labels LABEL_2003_03_11_2045 and LABEL_2003_03_11_2055!

BTW: Make sure you understood the "hardware handshake" done by the
MPC8xx! MPC8xx CTS/RTS have a different meaning than you might expect
when dealing with real UARTS! Basicly the only support flow control in
one direction! So a device can throttle the MPC. But the MPC can _not_
stop the device from sending more!

Hope this helps.

Steven


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

8xx SCC's as uart

[Eli Brin]

Hello,

I have noticed, in kernel 2.4.20, that SCC1 and SCC4 cannot be configured as
uarts.

Also, the configuration for RTS,CTS,DCD and DTR are missing.

Comparing 8xx_io/uart.c file to the 2.4.4 version of uart.c shows that all
the code to support the above has been removed, although both show driver
0.3.

Our target will use all SCC's as uarts with hardware handshake. So I will
need to put this back into uart.c and the config.in files.

Is there a reason for this feature (SCC1 and SCC4 as uarts are part of the
8xx ability) being removed ?

Thank you,
Eli Brin

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 8xx SCC's as uart

[Dan Malek]

Eli Brin wrote:

> I have noticed, in kernel 2.4.20, that SCC1 and SCC4 cannot be configured as
> uarts.

Ummmm....2.4.20 from where?

The linuxppc 2.4 development tree was updated by Gary Thomas a while
back to allow all possible SMC/SCC configurations within the resource
limitations of the particular processor variant.  This included the
baud rate generator restrictions on the 857.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: 8xx SCC's as uart

[Eli Brin]

Hello Dan,

Originally I was referring to both kernel.org and Denx.  But I was referred
to a patched 2.4.20 version from Denx that enables SCC1 and SCC4 as uarts
including RTS, CTS, DCD and DTR pin configuration.

I believe this should go into the kernel from kernel.org.  If one chooses to
use the 860(T/DT) or 855(T) processors why shouldn't he use SSC1 and 4 as
uarts.  The limitation of the 857 should not limit other processors.  Look
at the 852(T), it can use SCC4 as a uart.

Regarding the baud rate generators, we can configure the to more then one
uart, if those uarts use the same baud rate.  So, perhaps the BRG's should
be decoupled from the uart in the configuration.  This will go to the 8xx
CPM configuration witch is processor specific in the first place (FEC, SCC
and Ethernet and other 8xx processor variant stuff).

Thank you,
Eli Brin



-----Original Message-----
From: Dan Malek [mailto:dan@embeddededge.com]
Sent: Friday, July 18, 2003 6:28 PM
To: Eli Brin
Cc: 'linuxppc-embedded@lists.linuxppc.org'
Subject: Re: 8xx SCC's as uart


Eli Brin wrote:

> I have noticed, in kernel 2.4.20, that SCC1 and SCC4 cannot be
> configured as uarts.

Ummmm....2.4.20 from where?

The linuxppc 2.4 development tree was updated by Gary Thomas a while back to
allow all possible SMC/SCC configurations within the resource limitations of
the particular processor variant.  This included the baud rate generator
restrictions on the 857.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 8xx SCC's as uart

[Dean Matsen]

If anyone has interest, I have a patch against the 2.4.22-pre4/5
kernels that allows SCC1 to be a console (but still without
handshaking, in accord with this discussion thread) on 8xx builds.

We have a device where SCC1 is the only port connected to a DB-9, so
I had to do it.  The patch is modeled after the 8260 SCC console
stuff.

Problem is, the boot/8xx_io/boot/simple/m8xx_tty.c is kind of
messy because of an intertwined if/else and #ifdef/#else (we call
it a "conditional curly brace" at our office), so I do not know that
my patch is appropriate for all platforms.  It works on the one
device of ours that needs it...

Dean

Eli Brin wrote:

>Dear Wolfgang,
>
>Thanks, but I prefer to try it on the FADS.  I don't want anything "bad" to
>happen to the TQM860L.  The FADS is expendable...
>
>Thank you,
>Eli Brin
>
>
>-----Original Message-----
>From: Wolfgang Denk [mailto:wd@denx.de]
>Sent: Thursday, July 17, 2003 4:08 PM
>To: Eli Brin
>Cc: 'Steven Scholz'; 'linuxppc-embedded@lists.linuxppc.org'
>Subject: Re: 8xx SCC's as uart
>
>
>Dear Eli,
>
>in message <75DF04AC5ED4D511A9810090273CB4163F5DE9@rokonet-e.rokonet.co.il>
>you wrote:
>
>
>>When I will get our target, I will be able to test the HW flow control
>>of the 8xx and find a working mode with mgetty.  Our development
>>targets (TQM860L and FADS) don't have an SCC uart port...Perhaps I
>>will try to rewire the FADS that has SCC2 connected to an IRDA port...
>>
>>
>
>You can easily connect a UART port on a free SCC on the TQM860L - all 4 SCCs
>are available on  the  headers,  and  all  required  pins  are available  on
>the  STK8xxL  starter  kit board, too. You just need a RS232 line driver.
>
>
>Best regards,
>
>Wolfgang Denk
>
>--
>Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
>Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
>Thought for the day: What if there were no hypothetical situations?
>
>
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: 8xx SCC's as uart

[Eli Brin]

> Sure. If you don't care if data gets lost...

I would like to work on pure Tx/Rx without HW flow control.  But configuring
mgetty to work without flow control result in failure to detect disconnects.
Configuring mgetty to work with HW flow control result on detecting
disconnects.  All above experiments are on a PC.

When I will get our target, I will be able to test the HW flow control of
the 8xx and find a working mode with mgetty.  Our development targets
(TQM860L and FADS) don't have an SCC uart port...Perhaps I will try to
rewire the FADS that has SCC2 connected to an IRDA port...

Thanks for the warning... :)

Eli

-----Original Message-----
From: Steven Scholz [mailto:steven.scholz@imc-berlin.de]
Sent: Thursday, July 17, 2003 3:25 PM
To: linuxppc-embedded@lists.linuxppc.org
Subject: Re: 8xx SCC's as uart



Eli Brin wrote:

>> So you want to use the modem without hw flow control (RTS/CTS) ?
> No, it depends on mgetty.
>
> I think that mgetty need hw flow control (RTS/CTS) to monitor the DCD
> line.
???
I am not sure if I understand.

>
> I can rewire (short) the RTS/CTS on each side (modem and 8xx), and
> connect only DCD.

Sure. If you don't care if data gets lost...

Steven


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: 8xx SCC's as uart

[Eli Brin]

No, it depends on mgetty.

I think that mgetty need hw flow control (RTS/CTS) to monitor the DCD line.

I can rewire (short) the RTS/CTS on each side (modem and 8xx), and connect
only DCD.

Eli


-----Original Message-----
From: Steven Scholz [mailto:steven.scholz@imc-berlin.de]
Sent: Thursday, July 17, 2003 2:51 PM
To: Eli Brin
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: 8xx SCC's as uart


Eli Brin wrote:

> Dear Steven,
>
> I tested linuxppc_2_4_devel-2.4.20-2002_12_04.tar.bz2 snapshot from
> Denx ftp. I will get the version you referred me to.
>
> Regarding the hardware handshake, we will connect an SCC to a modem
> chip, and my tests show I need the DCD line from the modem so that
> mgetty (in autoppp mode) will detect disconnections.  It didn't detect
> disconnections without the modem handshake (DCD drop).
>
> We will try to get it working Tx.Rx only.
>

So you want to use the modem without hw flow control (RTS/CTS) ?

Steven

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 8xx SCC's as uart

[Steven Scholz]

Eli Brin wrote:

>> So you want to use the modem without hw flow control (RTS/CTS) ?
> No, it depends on mgetty.
>
> I think that mgetty need hw flow control (RTS/CTS) to monitor the DCD line.
???
I am not sure if I understand.

>
> I can rewire (short) the RTS/CTS on each side (modem and 8xx), and connect
> only DCD.

Sure. If you don't care if data gets lost...


Steven


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 8xx SCC's as uart

[Steven Scholz]

Eli Brin wrote:

> Dear Steven,
>
> I tested linuxppc_2_4_devel-2.4.20-2002_12_04.tar.bz2 snapshot from Denx
> ftp.
> I will get the version you referred me to.
>
> Regarding the hardware handshake, we will connect an SCC to a modem chip,
> and my tests show I need the DCD line from the modem so that mgetty (in
> autoppp mode) will detect disconnections.  It didn't detect disconnections
> without the modem handshake (DCD drop).
>
> We will try to get it working Tx.Rx only.
>

So you want to use the modem without hw flow control (RTS/CTS) ?

Steven


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/