MPC8xx: Using SCM/SCC and standard 16C550 Uarts together...

[Demke Torsten-atd012]

Hi David,

I dont know exactly the state of the DENX kernel, but in the standard
kernel the 8xx UART driver and the 16550 driver are using the same
device numbers (TTY_MAJOR) and device names (/dev/ttySx).
You have to change one of them.

Regards,
Torsten

> -----Original Message-----
> From: linuxppc-embedded-bounces at ozlabs.org
> [mailto:linuxppc-embedded-bounces at ozlabs.org]On Behalf Of David Jander
> Sent: Mittwoch, 12. Januar 2005 10:52
> To: linuxppc-embedded at ozlabs.org
> Subject: MPC8xx: Using SCM/SCC and standard 16C550 Uarts together...
> 
> 
> 
> Hi all,
> 
> The situation is:
> Our custom board needs to use SCM1 as console, and has an 
> external quad uart 
> chip (16C554) connected to the external bus, mapped at 0xf8100000.
> I am using the ppclinux_2_4_devel tree from Denx.
> I ioremapped that address space, and it seems to work. Right 
> now I don't have 
> the daughterboard with the quad-uarts working (as in 
> hardware), so I can't 
> fully test that.
> 
> The problem is:
> Apparently arch/ppc/8xx_io/uart.c doesn't take into account 
> other serial 
> drivers that may initialize later, and uses a serial_state 
> struct statically.
> Shouldn't this be visible to the outside? Shouldn't there be a global 
> serial_state structure somewhere that lists all serial ports?
> Right now, I get this:
> 
> -----------------------------------
> ...
> CPM UART driver version 0.04
> ttyS0 at 0x0280 is on SMC1 using BRG1
> ttyS1 at 0x0200 is on SCC3 using BRG2
> ttyS2 at 0x0300 is on SCC4 using BRG3
> pty: 256 Unix98 ptys configured
> Serial driver version 5.05c (2001-07-08) with MANY_PORTS 
> SHARE_IRQ enabled
> ...
> VFS: Mounted root (jffs2 filesystem).
> Mounted devfs on /dev
> Freeing unused kernel memory: 56k init
> ------------------------------------
> 
> And then nothing more. I assume, at that point init opens 
> /dev/console (ttyS0) 
> and that device doesn't exist, since drivers/char/serial.c 
> doesn't detect any 
> uart at the moment.
> If it did, maybe I would get console stuff out of the first 
> 16c554 port.
> 
> Has anybody else tried this?
> What would be the right way to fix this?
> 
> Greetings,
> 
> -- 
> David Jander
> Protonic Holland.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>