Skip to contentSkip to conversation

What happened to the serial console on BeagleBoard with 2.6.28-rc2?

PATCH In review Rick Bronson 6 participants 8 messages Nov 2, 2008 – Nov 3, 2008

lore
Share & tools
lore

Rick Bronson

author
#0 lore raw
Quoted 5 lines

Leaving only one map_desc[] entry left using MT_DEVICE not MT_MEMORY_SO... I didn't try this, since I'm currently not hooking up that serial port, but dmesg does show(*):

Quoted 7 lines

Serial: 8250/16550 driver3 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654 serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654 serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16650V2 console [ttyS2] enabled

Is that what you saw too?

Yep, that's what I saw, but only if I had DEBUG_LL=y. Without that
I had nothing except "Uncompressing Linux........". ST16650V2 is a clue that something went awry in auto-detection of the type of 8250 serial port. With the MT_MEMORY_SO change, I get:

Serial: 8250/16550 driver4 ports, IRQ sharing enabled serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654 serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654 serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654 console [ttyS2] enabled

I guess we don't see this problem on the other 2 ports since they
are mapped MT_MEMORY_SO and not MT_DEVICE (L4_34XX_PHYS).

Rick

#1 lore raw
Quoted 4 lines · Rick Bronson
Quoted 1 line

Is that what you saw too?

  Yep, that's what I saw, but only if I had DEBUG_LL=y.  Without that I had nothing except "Uncompressing Linux........".

I don't have DEBUG_LL=y ... if you had some kind of network link configured over USB, could you SSH in? (I can.)

Quoted 2 lines

  I guess we don't see this problem on the other 2 ports since they are mapped MT_MEMORY_SO and not MT_DEVICE (L4_34XX_PHYS).

Hmm, inconsistency is to be avoided. :)

I wonder what the root cause is ... is the driver missing various barriers needed to make MT_DEVICE work? Or is the MT_DEVICE incorrect in the first place? "git whatchanged" didn't show any recent changes that seemed (on a quick glance) to affect I/O at that level. Maybe it was one of the other TTY changes interacting here.

- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw

PATCH 1/1 serial: Flush posted write on 34xx to make 8250 work (Re: What happened to the serial console on BeagleBoard with 2.6.28-rc2?)

Quoted 13 lines · David Brownell
Quoted 4 lines · Rick Bronson
Quoted 1 line

Is that what you saw too?

  Yep, that's what I saw, but only if I had DEBUG_LL=y.  Without that I had nothing except "Uncompressing Linux........".

I don't have DEBUG_LL=y ... if you had some kind of network link configured over USB, could you SSH in? (I can.)

Quoted 2 lines

  I guess we don't see this problem on the other 2 ports since they are mapped MT_MEMORY_SO and not MT_DEVICE (L4_34XX_PHYS).

Quoted 8 lines

Hmm, inconsistency is to be avoided. :)

I wonder what the root cause is ... is the driver missing various barriers needed to make MT_DEVICE work? Or is the MT_DEVICE incorrect in the first place? "git whatchanged" didn't show any recent changes that seemed (on a quick glance) to affect I/O at that level. Maybe it was one of the other TTY changes interacting here.

Yeah I don't know what may have changed, or have things just gotten faster now with cortex since 2.6.27?

Anyways, this patch fixes the issue for me without marking things strongly ordered. Rick, does this work for you?

Regards,

Tony

Quoted 1 line

From 57eea529292418a20a119c5b18d7636cf44992ae Mon Sep 17 00:00:00 2001

From: Tony Lindgren <[email protected]>
Date: Fri, 31 Oct 2008 16:47:42 -0700
Subject: [PATCH] serial: Flush posted write on 34xx to make 8250 work

On omap34xx, we need to flush posted writes for TX.

Signed-off-by Tony Lindgren <[email protected]>
drivers/serial/8250.c +7 -0
index 5f383d8..629a16c 100644
@@ -413,6 +413,13 @@ serial_out(struct uart_8250_port *up, int offset, int value)
 
 	case UPIO_MEM:
 		writeb(value, up->port.membase + offset);
+#ifdef CONFIG_ARCH_OMAP
+		/* Flush posted write for TX */
+		if (cpu_is_omap34xx() && is_omap_port(up) &&
+			(save_offset == UART_TX || save_offset == UART_IER ||
+				save_offset == UART_LCR))
+			value = serial_in(up, UART_LCR); /* Safe to read */
+#endif
 		break;
 
 	case UPIO_RM9000:
#3 lore raw

Re: [PATCH] serial: Flush posted write on 34xx to make 8250 work (Re:

Quoted 1 line

does this work for you?

Works on Pandora, which had garbled text instead of no output at all.

#4 lore raw

Re: [PATCH] serial: Flush posted write on 34xx to make 8250 work (Re: What happened to the serial console on BeagleBoard with 2.6.28-rc2?)

In reply to Tony Lindgren

2008/11/3 Tony Lindgren <[email protected]>:

Quoted 23 lines · David Brownell
Quoted 13 lines · Rick Bronson
Quoted 4 lines
Quoted 1 line

Is that what you saw too?

Yep, that's what I saw, but only if I had DEBUG_LL=y. Without that
I had nothing except "Uncompressing Linux........".

I don't have DEBUG_LL=y ... if you had some kind of network link configured over USB, could you SSH in? (I can.)

Quoted 2 lines

I guess we don't see this problem on the other 2 ports since they
are mapped MT_MEMORY_SO and not MT_DEVICE (L4_34XX_PHYS).

Quoted 8 lines

Hmm, inconsistency is to be avoided. :)

I wonder what the root cause is ... is the driver missing various barriers needed to make MT_DEVICE work? Or is the MT_DEVICE incorrect in the first place? "git whatchanged" didn't show any recent changes that seemed (on a quick glance) to affect I/O at that level. Maybe it was one of the other TTY changes interacting here.

Quoted 5 lines

Yeah I don't know what may have changed, or have things just gotten faster now with cortex since 2.6.27?

Anyways, this patch fixes the issue for me without marking things strongly ordered. Rick, does this work for you?

This patch still works for me.
Thanks!

Quoted 5 lines

Regards,

Tony

Signature · 1 line
Lei Ming
#5 lore raw

Re: [PATCH] serial: Flush posted write on 34xx to make 8250 work (Re: What happened to the serial console on BeagleBoard with 2.6.28-rc2?)

Quoted 24 lines · Ming Lei

2008/11/3 Tony Lindgren <[email protected]>:

Quoted 23 lines · David Brownell
Quoted 21 lines · Rick Bronson
Quoted 4 lines
Quoted 1 line

Is that what you saw too?

Yep, that's what I saw, but only if I had DEBUG_LL=y. Without that
I had nothing except "Uncompressing Linux........".

I don't have DEBUG_LL=y ... if you had some kind of network link configured over USB, could you SSH in? (I can.)

Quoted 2 lines

I guess we don't see this problem on the other 2 ports since they
are mapped MT_MEMORY_SO and not MT_DEVICE (L4_34XX_PHYS).

Hmm, inconsistency is to be avoided. :)

I wonder what the root cause is ... is the driver missing various barriers needed to make MT_DEVICE work? Or is the MT_DEVICE incorrect in the first place? "git whatchanged" didn't show any recent changes that seemed (on a quick glance) to affect I/O at that level. Maybe it was one of the other TTY changes interacting here.

Quoted 8 lines
Quoted 5 lines

Yeah I don't know what may have changed, or have things just gotten faster now with cortex since 2.6.27?

Anyways, this patch fixes the issue for me without marking things strongly ordered. Rick, does this work for you?

This patch still works for me.
Thanks!

Well the real problem has been found, there's a bug with the recent ptebits patches, which causes section mappings to be just MT_MEMORY instead of MT_DEVICE..

So let's put things on hold until we have a real fix for that on the linux-arm-kernel mailing list, hopefully today.

Regards,

Tony

#6 lore raw

RE: [PATCH] serial: Flush posted write on 34xx to make 8250 work (Re: What happened to the serial console on BeagleBoard with 2.6.28-rc2?)

Quoted 9 lines

From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Tony Lindgren
Well the real problem has been found, there's a bug with the recent ptebits patches, which causes section mappings to be just MT_MEMORY instead of MT_DEVICE..

So let's put things on hold until we have a real fix for that on the linux-arm-kernel mailing list, hopefully today.

That makes a lot more sense. It was odd to see a flurry of failures.

SO vs. DEVICE were occasional errors usually seen under irq stress. It never took down the serial port. Mapping things a MEMORY surely would.

Regards,
Richard W.

#7 lore raw
In reply to Rick Bronson
Quoted 18 lines · Rick Bronson
Quoted 5 lines

Leaving only one map_desc[] entry left using MT_DEVICE not MT_MEMORY_SO... I didn't try this, since I'm currently not hooking up that serial port, but dmesg does show(*):

Quoted 7 lines

Serial: 8250/16550 driver3 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654 serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654 serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16650V2 console [ttyS2] enabled

Is that what you saw too?

Yep, that's what I saw, but only if I had DEBUG_LL=y. Without that
I had nothing except "Uncompressing Linux........". ST16650V2 is a clue that something went awry in auto-detection of the type of 8250 serial port. With the MT_MEMORY_SO change, I get:

Quoted 8 lines

Serial: 8250/16550 driver4 ports, IRQ sharing enabled serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654 serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654 serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654 console [ttyS2] enabled

I guess we don't see this problem on the other 2 ports since they
are mapped MT_MEMORY_SO and not MT_DEVICE (L4_34XX_PHYS).

Rick, can you please reply with your Signed-off-by for your patch?

Let's push that one, then continue thinking about the so/device issues.

Tony