[#3995] kernel hangs when accessing uart 0 on bf537 when booting u-boot and linux on uart 1

Document created by Aaronwu Employee on Aug 28, 2013
Version 1Show Document
  • View in full screen mode

[#3995] kernel hangs when accessing uart 0 on bf537 when booting u-boot and linux on uart 1

Submitted By: Robert Selberg

Open Date

2008-03-28 10:27:30     Close Date

2008-04-01 17:01:48

Priority:

Medium     Assignee:

Sonic Zhang

Status:

Closed     Fixed In Release:

N/A

Found In Release:

2007R1.1-RC3     Release:

Category:

Drivers     Board:

N/A

Processor:

BF537     Silicon Revision:

Is this bug repeatable?:

Yes     Resolution:

Fixed

Uboot version or rev.:

    Toolchain version or rev.:

App binary format:

N/A     

Summary: kernel hangs when accessing uart 0 on bf537 when booting u-boot and linux on uart 1

Details:

 

The Linux kernel hangs on these lines in linux/drivers/serial/bfin_5xx.c (bfin_serial_set_termios) when accessing uart 0 if the system is booted on uart 1 on a bf537 system:

 

do {

    lsr = UART_GET_LSR(uart);

} while (!(lsr & TEMT));

 

The kernel hangs because the UCEN bit in UART0_GCTL is not set and the loop will loop forever. I have not tried if this bug exists in the svn version but it seems so after a quick look at the code.

 

A suggested fix is to remove this code or enabling the uart clock before the loop.

 

Follow-ups

 

--- Sonic Zhang                                              2008-03-31 03:18:54

Applied.

 

--- Mike Frysinger                                           2008-03-31 10:09:05

i dont think that's the correct fix ... we should drop the loop altogether

 

the low level set termios function does not care about the state of the serial

line wrt data going out.  that is handled at the higher levels via

TCSANOW/TCSADRAIN/etc...  if the user does tcsetattr(TCSANOW) and a byte is in

transit, the expected behavior is for that byte to basically be corrupted.

 

--- Sonic Zhang                                              2008-03-31 22:47:22

But, this code does better to avoid corruption in any cases. Why the corruption

is expected if the driver can avoid?

 

--- Mike Frysinger                                           2008-03-31 23:44:30

if you want to go by the spec, this loop violates things.

 

  www.opengroup.org/onlinepubs/009695399/functions/tcsetattr.html

If optional_actions is TCSANOW, the change shall occur immediately.

 

it also doesnt really gain us anything as the expected behavior is corruption,

so a programmer will already be accounting for it.

 

--- Sonic Zhang                                              2008-04-01 02:21:02

Removed.

 

--- Sonic Zhang                                              2008-04-01 02:21:33

Dropped

 

--- Mike Frysinger                                           2008-04-01 17:01:48

thanks

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

No Files Were Found

Attachments

    Outcomes