8250 UART doesn't work

8250 UART doesn't work

[Woody Wu]

Hi, list

Does anyone here familiar to the serial 8250 driver?

I enabled two uart ports in my board definition, but the ports doesn't
appear after I loaded the kernel (3.4.19).  I discovered, it failed at
the UART port auto configuration stage, the exact function is
autoconfig(...) in drivers/tty/serial/8250.c.

...
    if (!(port->flags & UPF_BUGGY_UART)) {
        scratch = serial_in(up, UART_IER);
        serial_out(up, UART_IER, 0);
#ifdef __i386__
        outb(0xff, 0x080);
#endif
        /*
         * Mask out IER[7:4] bits for test as some UARTs (e.g. TL
         * 16C754B) allow only to modify them if an EFR bit is set.
         */
        scratch2 = serial_in(up, UART_IER) & 0x0f;
        serial_out(up, UART_IER, 0x0F);
#ifdef __i386__
        outb(0, 0x080);
#endif
        scratch3 = serial_in(up, UART_IER) & 0x0f;
        serial_out(up, UART_IER, scratch);
        if (scratch2 != 0 || scratch3 != 0x0F) {
            /*
             * We failed; there's nothing here
             */
            DEBUG_AUTOCONF("IER test failed (%02x, %02x) ",
                       scratch2, scratch3);
            goto out;
        }
    }

By enabling the debug output, I found it failed because values in scratch2 and
scratch3 are all zeros.


In my board definition, what I configured are something like:

#define SERIAL_BASE  (0xe1400000)
#define SERIAL_FLAGS (UPF_BOOT_AUTOCONF | UPF_IOREMAP | UPF_SHARE_IRQ)
#define SERIAL_CLK   (14745600) 

static struct plat_serial8250_port lgf2410_urts_data[] = {
    [0] = {
        .mapbase    = SERIAL_BASE + 0x00,
        .irq        = 16,
        .flags      = SERIAL_FLAGS,
        .iotype     = UPIO_MEM,
        .regshift   = 0,
        .uartclk    = SERIAL_CLK,
    },
    [1] = {
        .mapbase    = SERIAL_BASE + 0x10,
        .irq        = 17,
        .flags      = SERIAL_FLAGS,
        .iotype     = UPIO_MEM,
        .regshift   = 0,
        .uartclk    = SERIAL_CLK,
    },
};

static struct platform_device lgf2410_urts = {
    .name           = "serial8250",
    .id         = PLAT8250_DEV_PLATFORM,
    .dev            = {
        .platform_data  = &lgf2410_urts_data,
    },
};

I think the mapbase addresses are corrected. Since I copied these addresse from
a old kernel log output from a 2.6.16 linux. For the old 2.6.16 kernel, which
run the exact same board, I have no information how it was configured.

Below is the 2.6.16 kernel output, it successfully detected the UART
ports:

serial8250: tts0 at MMIO 0xe1400000 (irq = 16) is a 16550A
serial8250: tts1 at MMIO 0xe1400008 (irq = 16) is a 16550A
serial8250: tts2 at MMIO 0xe1400010 (irq = 17) is a 16550A
serial8250: tts3 at MMIO 0xe1400018 (irq = 17) is a 16550A

Now I expect the same result from my self tailored 3.4.19 kernel.

Hope I can get your kind support! Thanks.


-- 
woody
I can't go back to yesterday - because I was a different person then.

Re: 8250 UART doesn't work

[H. Peter Anvin]

On 12/05/2012 11:56 PM, Woody Wu wrote:
> Hi, list
>
> Does anyone here familiar to the serial 8250 driver?
>
> I enabled two uart ports in my board definition, but the ports doesn't
> appear after I loaded the kernel (3.4.19).  I discovered, it failed at
> the UART port auto configuration stage, the exact function is
> autoconfig(...) in drivers/tty/serial/8250.c.
>

Sounds like you're using some kind of buggy UART IP... sharing which one 
might help people identify the problem, if they have seen it before.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: 8250 UART doesn't work

[Woody Wu]

On 2012-12-06, H. Peter Anvin <hpa@zytor.com> wrote:
> On 12/05/2012 11:56 PM, Woody Wu wrote:
>> Hi, list
>>
>> Does anyone here familiar to the serial 8250 driver?
>>
>> I enabled two uart ports in my board definition, but the ports doesn't
>> appear after I loaded the kernel (3.4.19).  I discovered, it failed at
>> the UART port auto configuration stage, the exact function is
>> autoconfig(...) in drivers/tty/serial/8250.c.
>>
>
> Sounds like you're using some kind of buggy UART IP... sharing which one 
> might help people identify the problem, if they have seen it before.
>
> 	-hpa
>

The UART controller is EXAR ST16C554D.  It claims as a 16550
compatible controller. Each ST16C554D module contains 4 UART, each of
them can be selected via two chip select pad. I think the board
hardware, via a CPLD, make the chip selection transparent to the CPU, so
by a 5-bit address, CPU can addressing individual 8 16550 compatible
registers of each UART.

I am not one hundred  percent sure I understood right, but this is all I
can say.  You experts can also judge whether this kind of hardware setup
is normal in embedded multi-serial ports solutions.

Many thanks!

-- 
woody
I can't go back to yesterday - because I was a different person then.

Re: 8250 UART doesn't work

[Alan Cox]

> The UART controller is EXAR ST16C554D.  It claims as a 16550
> compatible controller. Each ST16C554D module contains 4 UART, each of
> them can be selected via two chip select pad. I think the board
> hardware, via a CPLD, make the chip selection transparent to the CPU, so
> by a 5-bit address, CPU can addressing individual 8 16550 compatible
> registers of each UART.

The EXAR should work. Make sure you have all the addressing and setup
right would be my first suggestion - then poke at the registers by hand
and double check.

Alan

Re: 8250 UART doesn't work

[Woody Wu]

On 2012-12-07, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> The UART controller is EXAR ST16C554D.  It claims as a 16550
>> compatible controller. Each ST16C554D module contains 4 UART, each of
>> them can be selected via two chip select pad. I think the board
>> hardware, via a CPLD, make the chip selection transparent to the CPU, so
>> by a 5-bit address, CPU can addressing individual 8 16550 compatible
>> registers of each UART.
>
> The EXAR should work. Make sure you have all the addressing and setup
> right would be my first suggestion - then poke at the registers by hand
> and double check.
>
> Alan

Do you think my iotype (UPIO_MEM) and flags ((UPF_BOOT_AUTOCONF |
UPF_IOREMAP | UPF_SHARE_IRQ)) settings are normal in a ARM board?

In the same directory with the 8250.c driver source, I foudn a 16C554
ports definition file 8250_exar_st16c554.c, in which the UART
definitions are quite different with that in my case:

#define PORT(_base,_irq)				\
	{						\
		.iobase		= _base,		\
		.irq		= _irq,			\
		.uartclk	= 1843200,		\
		.iotype		= UPIO_PORT,		\
		.flags		= UPF_BOOT_AUTOCONF,	\
	}

static struct plat_serial8250_port exar_data[] = {
	PORT(0x100, 5),
	PORT(0x108, 5),
	PORT(0x110, 5),
	PORT(0x118, 5),
	{ },
};

You see this file use UPIO_PORT as iotype and provide not mapbase but
iobase.

Which kind of configuration is right for ARM?  I think the
8250_exar_st16c554.c is for ISA bus board and hence is not suit to me,
but I am not sure my understanding is right. Please give me some
backgroud information on this field.

Thanks.


-- 
woody
I can't go back to yesterday - because I was a different person then.

Re: 8250 UART doesn't work

[Alan Cox]

> Which kind of configuration is right for ARM?  I think the
> 8250_exar_st16c554.c is for ISA bus board and hence is not suit to me,
> but I am not sure my understanding is right. Please give me some
> backgroud information on this field.

You are the one who should have the information for your board. If not
ask your board vendor how it is all mapped.

Alan

Re: 8250 UART doesn't work

[Woody Wu]

On 2012-12-08, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Which kind of configuration is right for ARM?  I think the
>> 8250_exar_st16c554.c is for ISA bus board and hence is not suit to me,
>> but I am not sure my understanding is right. Please give me some
>> backgroud information on this field.
>
> You are the one who should have the information for your board. If not
> ask your board vendor how it is all mapped.
>
> Alan

I have no more information for the board. For now, I just want to gain
some knowledge about the UPIO_MEM and UPIO_PORT - what is for what.
Hope experts on the list can be so kind to help me.  Thanks.


-- 
woody
I can't go back to yesterday - because I was a different person then.