* SCCx UART status on 8xx
@ 2006-02-20 13:37 Björn Östby
2006-02-20 14:18 ` Aristeu Sergio Rozanski Filho
2006-02-20 20:15 ` Wolfgang Denk
0 siblings, 2 replies; 6+ messages in thread
From: Björn Östby @ 2006-02-20 13:37 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I'm messing with a mpc823e based board trying to enable the SCC3 UART. =
I'm using the 2.4.25 denx linux_ppc kernel and I've got SMC1 for console =
and SMC2 up and running but I'm in desperate need of another rs232 port =
(which is on SCC3 on my board).=20
Reading quite a lot of old posts on this mailing list got me confused =
whether the SCCx UART support in the kernel is ready to be used on 8xx =
or if there will take a large amount of hacking to get things going =
(reading the header of 8xx_io/uart.c got me wondering even more).
Current situation is that I have enabled the SCC3 UART in the kernel, =
set the correct CTS, RTS and CD signal options and finally disabled the =
SPI which (on my board at least) can override the UART on the third SCC =
port. During boot up I get the standard output:
>ttyS0 at 0x0280 is on SMC1 using BRG1
>ttyS1 at 0x0380 is on SMC2 using BRG2
>ttyS2 at 0x0200 is on SCC3 using BRG3
Writing to ttyS0 and ttyS1 works fine (the result pop up in the =
receiving terminal) but when trying ttyS2 nothing happens. I've checked =
the Tx signal and it appears as if data is sent (the signal gets noisy =
when starting the write procedure). I may also add that restaring the =
write application causes the kernel to hang (for ttyS2 only of course).
I've read some posts saying that Linux don't init other uart ports than =
the console port and that is the potential problem here, but it is =
unclear if this statement is true or not. I can also add to the problem =
description that my SMC2 port works fine for writing, but reading just =
hangs in the read() call. So, can anyone confirm any status on the SMCx =
and SCCx UART drivers for 2.4?
Best regards,
Bjorn ostby
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SCCx UART status on 8xx
2006-02-20 13:37 SCCx UART status on 8xx Björn Östby
@ 2006-02-20 14:18 ` Aristeu Sergio Rozanski Filho
2006-03-11 22:17 ` Marcelo Tosatti
2006-02-20 20:15 ` Wolfgang Denk
1 sibling, 1 reply; 6+ messages in thread
From: Aristeu Sergio Rozanski Filho @ 2006-02-20 14:18 UTC (permalink / raw)
To: Björn Östby; +Cc: fbl, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]
On Mon, Feb 20, 2006 at 02:37:23PM +0100, Björn Östby wrote:
> Hello,
> I'm messing with a mpc823e based board trying to enable the SCC3 UART. I'm using the 2.4.25 denx linux_ppc kernel and I've got SMC1 for console and SMC2 up and running but I'm in desperate need of another rs232 port (which is on SCC3 on my board).
> Reading quite a lot of old posts on this mailing list got me confused whether the SCCx UART support in the kernel is ready to be used on 8xx or if there will take a large amount of hacking to get things going (reading the header of 8xx_io/uart.c got me wondering even more).
> Current situation is that I have enabled the SCC3 UART in the kernel, set the correct CTS, RTS and CD signal options and finally disabled the SPI which (on my board at least) can override the UART on the third SCC port. During boot up I get the standard output:
>
> >ttyS0 at 0x0280 is on SMC1 using BRG1
> >ttyS1 at 0x0380 is on SMC2 using BRG2
> >ttyS2 at 0x0200 is on SCC3 using BRG3
>
> Writing to ttyS0 and ttyS1 works fine (the result pop up in the receiving terminal) but when trying ttyS2 nothing happens. I've checked the Tx signal and it appears as if data is sent (the signal gets noisy when starting the write procedure). I may also add that restaring the write application causes the kernel to hang (for ttyS2 only of course).
>
> I've read some posts saying that Linux don't init other uart ports than the console port and that is the potential problem here, but it is unclear if this statement is true or not. I can also add to the problem description that my SMC2 port works fine for writing, but reading just hangs in the read() call. So, can anyone confirm any status on the SMCx and SCCx UART drivers for 2.4?
please try the two attached patches. the first one configures each SCC to
one BRG. the second one, makes use always of dpram memory. we're working on a
decent fix.
Marcelo: if you find the first one ok, you may apply it, but don't apply the
second
--
Aristeu
[-- Attachment #2: cpm_uart-configure_brgs_properly.patch --]
[-- Type: text/plain, Size: 1028 bytes --]
Index: stable/drivers/serial/cpm_uart/cpm_uart_cpm1.c
===================================================================
--- stable.orig/drivers/serial/cpm_uart/cpm_uart_cpm1.c 2006-02-17 17:11:37.000000000 -0200
+++ stable/drivers/serial/cpm_uart/cpm_uart_cpm1.c 2006-02-17 17:15:57.000000000 -0200
@@ -139,24 +139,31 @@
void scc1_lineif(struct uart_cpm_port *pinfo)
{
/* XXX SCC1: insert port configuration here */
+ cpmp->cp_sicr &= 0xFFFFFFC0;
pinfo->brg = 1;
}
void scc2_lineif(struct uart_cpm_port *pinfo)
{
/* XXX SCC2: insert port configuration here */
+ cpmp->cp_sicr &= 0xFFFFC0FF;
+ cpmp->cp_sicr |= 0x00000900;
pinfo->brg = 2;
}
void scc3_lineif(struct uart_cpm_port *pinfo)
{
/* XXX SCC3: insert port configuration here */
+ cpmp->cp_sicr &= 0xFFC0FFFF;
+ cpmp->cp_sicr |= 0x00140000;
pinfo->brg = 3;
}
void scc4_lineif(struct uart_cpm_port *pinfo)
{
/* XXX SCC4: insert port configuration here */
+ cpmp->cp_sicr &= 0xC0FFFFFF;
+ cpmp->cp_sicr |= 0x1BFFFFFF;
pinfo->brg = 4;
}
[-- Attachment #3: serial_alloc_bootmem.patch --]
[-- Type: text/plain, Size: 1131 bytes --]
Index: stable/drivers/serial/cpm_uart/cpm_uart_core.c
===================================================================
--- stable.orig/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-07 15:30:42.000000000 -0200
+++ stable/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-08 12:39:11.000000000 -0200
@@ -467,6 +467,7 @@
/* free interrupt handler */
free_irq(port->irq, port);
+#if 0
/* If the port is not the console, disable Rx and Tx. */
if (!(pinfo->flags & FLAG_CONSOLE)) {
/* Wait for all the BDs marked sent */
@@ -492,6 +493,7 @@
/* Shut them really down */
cpm_line_cr_cmd(line, CPM_CR_STOP_TX);
}
+#endif
}
static void cpm_uart_set_termios(struct uart_port *port,
@@ -896,7 +898,7 @@
pinfo->sccp->scc_gsmrl &= ~(SCC_GSMRL_ENR | SCC_GSMRL_ENT);
}
- ret = cpm_uart_allocbuf(pinfo, 0);
+ ret = cpm_uart_allocbuf(pinfo, 1);
if (ret)
return ret;
@@ -912,10 +914,12 @@
static void cpm_uart_release_port(struct uart_port *port)
{
+#if 0
struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
if (!(pinfo->flags & FLAG_CONSOLE))
cpm_uart_freebuf(pinfo);
+#endif
}
/*
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: SCCx UART status on 8xx
2006-02-20 14:18 ` Aristeu Sergio Rozanski Filho
@ 2006-03-11 22:17 ` Marcelo Tosatti
0 siblings, 0 replies; 6+ messages in thread
From: Marcelo Tosatti @ 2006-03-11 22:17 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho
Cc: fbl, Björn Östby, linuxppc-embedded
Aris,
Can you please prepare a detailed description of what the
patch is doing and why?
Thanks
On Mon, Feb 20, 2006 at 11:18:35AM -0300, Aristeu Sergio Rozanski Filho wrote:
> Index: stable/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> ===================================================================
> --- stable.orig/drivers/serial/cpm_uart/cpm_uart_cpm1.c 2006-02-17 17:11:37.000000000 -0200
> +++ stable/drivers/serial/cpm_uart/cpm_uart_cpm1.c 2006-02-17 17:15:57.000000000 -0200
> @@ -139,24 +139,31 @@
> void scc1_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC1: insert port configuration here */
> + cpmp->cp_sicr &= 0xFFFFFFC0;
> pinfo->brg = 1;
> }
>
> void scc2_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC2: insert port configuration here */
> + cpmp->cp_sicr &= 0xFFFFC0FF;
> + cpmp->cp_sicr |= 0x00000900;
> pinfo->brg = 2;
> }
>
> void scc3_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC3: insert port configuration here */
> + cpmp->cp_sicr &= 0xFFC0FFFF;
> + cpmp->cp_sicr |= 0x00140000;
> pinfo->brg = 3;
> }
>
> void scc4_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC4: insert port configuration here */
> + cpmp->cp_sicr &= 0xC0FFFFFF;
> + cpmp->cp_sicr |= 0x1BFFFFFF;
> pinfo->brg = 4;
> }
>
> Index: stable/drivers/serial/cpm_uart/cpm_uart_core.c
> ===================================================================
> --- stable.orig/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-07 15:30:42.000000000 -0200
> +++ stable/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-08 12:39:11.000000000 -0200
> @@ -467,6 +467,7 @@
> /* free interrupt handler */
> free_irq(port->irq, port);
>
> +#if 0
> /* If the port is not the console, disable Rx and Tx. */
> if (!(pinfo->flags & FLAG_CONSOLE)) {
> /* Wait for all the BDs marked sent */
> @@ -492,6 +493,7 @@
> /* Shut them really down */
> cpm_line_cr_cmd(line, CPM_CR_STOP_TX);
> }
> +#endif
> }
>
> static void cpm_uart_set_termios(struct uart_port *port,
> @@ -896,7 +898,7 @@
> pinfo->sccp->scc_gsmrl &= ~(SCC_GSMRL_ENR | SCC_GSMRL_ENT);
> }
>
> - ret = cpm_uart_allocbuf(pinfo, 0);
> + ret = cpm_uart_allocbuf(pinfo, 1);
>
> if (ret)
> return ret;
> @@ -912,10 +914,12 @@
>
> static void cpm_uart_release_port(struct uart_port *port)
> {
> +#if 0
> struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
>
> if (!(pinfo->flags & FLAG_CONSOLE))
> cpm_uart_freebuf(pinfo);
> +#endif
> }
>
> /*
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SCCx UART status on 8xx
2006-02-20 13:37 SCCx UART status on 8xx Björn Östby
2006-02-20 14:18 ` Aristeu Sergio Rozanski Filho
@ 2006-02-20 20:15 ` Wolfgang Denk
2006-02-20 20:43 ` Dan Malek
1 sibling, 1 reply; 6+ messages in thread
From: Wolfgang Denk @ 2006-02-20 20:15 UTC (permalink / raw)
To: Björn Östby; +Cc: linuxppc-embedded
In message <004B1D7A5257174C9044A1B7BD0E60ED0178CC4F@ratatosk.combitechsystems.com> you wrote:
>
> I'm messing with a mpc823e based board trying to enable the SCC3 UART. I'm using the 2.4.25 denx linux_ppc kernel and I've got SMC1 for console and SMC2 up and running but I'm in desperate need of another rs232 port (which is on SCC3 on my board).
> Reading quite a lot of old posts on this mailing list got me confused whether the SCCx UART support in the kernel is ready to be used on 8xx or if there will take a large amount of hacking to get things going (reading the header of 8xx_io/uart.c got me
> wondering even more).
All UARTS (up to 2 x SMC + 4 x SCC, depending on CPU model) can be
used with our tree, including hardware handshake.
> I've read some posts saying that Linux don't init other uart ports than the console port and that is the potential problem here, but it is unclear if this statement is true or not. I can also add to the problem description that my SMC2 port works fine f
> or writing, but reading just hangs in the read() call. So, can anyone confirm any status on the SMCx and SCCx UART drivers for 2.4?
Works fine on all board supported by us.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The C-shell doesn't parse. It adhoculates.
- Casper.Dik@Holland.Sun.COM in <3ol96k$b2j@engnews2.Eng.Sun.COM>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: SCCx UART status on 8xx
2006-02-20 20:15 ` Wolfgang Denk
@ 2006-02-20 20:43 ` Dan Malek
0 siblings, 0 replies; 6+ messages in thread
From: Dan Malek @ 2006-02-20 20:43 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Björn Östby, linuxppc-embedded
On Feb 20, 2006, at 3:15 PM, Wolfgang Denk wrote:
> All UARTS (up to 2 x SMC + 4 x SCC, depending on CPU model) can be
> used with our tree, including hardware handshake.
Except that you have to be careful about BRG allocation. At most,
the 8xx will have 4 BRGs, some only have 2. There have been various
implementations to work with this, some forced the BRGs to be
multiply mapped (where more than one UART had to run at the same rate)
while others silently returned errors and the UARTs were non-functional
although appeared for use.
Thanks.
-- Dan
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: SCCx UART status on 8xx
@ 2006-02-21 11:01 Björn Östby
0 siblings, 0 replies; 6+ messages in thread
From: Björn Östby @ 2006-02-21 11:01 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: fbl, linuxppc-embedded
Hi all again,
-----Original Message-----
From: Aristeu Sergio Rozanski Filho [mailto:aris@mandriva.com]=20
Sent: den 20 februari 2006 15:19
To: Bj=F6rn =D6stby
Cc: linuxppc-embedded@ozlabs.org; marcelo.tosatti@cyclades.com; =
fbl@conectiva.com.br
Subject: Re: SCCx UART status on 8xx
On Mon, Feb 20, 2006 at 02:37:23PM +0100, Bj=F6rn =D6stby wrote:
> Hello,
> I'm messing with a mpc823e based board trying to enable the SCC3 UART. =
> I'm using the 2.4.25 denx linux_ppc kernel and I've got SMC1 for =
console and SMC2 up and running but I'm in desperate need of another =
rs232 port (which is on SCC3 on my board).
> Reading quite a lot of old posts on this mailing list got me confused =
whether the SCCx UART support in the kernel is ready to be used on 8xx =
or if there will take a large amount of hacking to get things going =
(reading the header of 8xx_io/uart.c got me wondering even more).
> Current situation is that I have enabled the SCC3 UART in the kernel, =
set the correct CTS, RTS and CD signal options and finally disabled the =
SPI which (on my board at least) can override the UART on the third SCC =
port. During boot up I get the standard output:
>=20
> >ttyS0 at 0x0280 is on SMC1 using BRG1
> >ttyS1 at 0x0380 is on SMC2 using BRG2
> >ttyS2 at 0x0200 is on SCC3 using BRG3
>=20
> Writing to ttyS0 and ttyS1 works fine (the result pop up in the=20
> receiving terminal) but when trying ttyS2 nothing happens. I've=20
> checked the Tx signal and it appears as if data is sent (the signal=20
> gets noisy when starting the write procedure). I may also add that=20
> restaring the write application causes the kernel to hang (for ttyS2=20
> only of course).
>=20
> I've read some posts saying that Linux don't init other uart ports=20
> than the console port and that is the potential problem here, but it =
is unclear if this >>
>statement is true or not. I can also add to the problem description =
that my SMC2 port works >fine for writing, but reading just hangs in the =
read() call. So, can anyone confirm any >
>status on the SMCx and SCCx UART drivers for 2.4?
>please try the two attached patches. the first one configures each SCC =
to one BRG. the second one, makes use always of dpram memory. we're =
working on a decent fix.
>Marcelo: if you find the first one ok, you may apply it, but don't =
apply the second
>
>--=20
>Aristeu
>
I would like to thank everyone who has given input to the discussion. =
Unfortunately the problems remain. I have not been able to try the =
patches since I reckon they are for Linux 2.6 specific while I'm using =
the 2.4 kernel (could be good to have in for future projects though). I =
did however triy remove the CTS, RTS and CD signal from the config as =
suggested which stopped the kernel from hanging. Might be a step in the =
right direction.
Best regards,
Bjorn Ostby
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-03-11 19:22 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-20 13:37 SCCx UART status on 8xx Björn Östby
2006-02-20 14:18 ` Aristeu Sergio Rozanski Filho
2006-03-11 22:17 ` Marcelo Tosatti
2006-02-20 20:15 ` Wolfgang Denk
2006-02-20 20:43 ` Dan Malek
-- strict thread matches above, loose matches on Subject: below --
2006-02-21 11:01 Björn Östby
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).