This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How to Setup UART0 & UART1 on OMAP-L137 in montavista Linux?

Other Parts Discussed in Thread: OMAP-L137, DA8XX, OMAP-L138

Hi,

     I use the OMAP-L137 Processor but not evm. As we all know, OMAP-L137 have three uarts , but  evm  only use  uart2 to be a console , and no use uart 0 and uart1.

so , how can i to setup uart0 and uart1 in linux ?

  • As I have just the EVM, I can not completely test the UART0 and 1. But if I do a software test

    cat /proc/tty/driver/serial

    echo "test" > /dev/ttyS2

    echo "test" > /dev/ttyS1

    echo "test" > /dev/ttyS0

    cat /proc/tty/driver/serial

    You should see the TX numbers increasing for the 3 serial ports meaning that the software is working for them.

    The driver was made/tested for the UART2 hardware though, so I'm not sure it any other adaptation is needed.

    One thing that I know it will probably necessary is to change the pinmux. UART0 and 1 pins are muxed with other peripherals (please see the pinmux utility). So you need to make sure that you are not going to use the conflicting peripherals and then change the pimux to enabled the hardware:

    http://community.ti.com/forums/p/11996/48088.aspx#48088

    But again, I have not tested, so I'm not sure if that is all that is necessary, maybe someone else in the community can have a better input.

  • Yes,  I use this method  to test the  uart driver :

    root@epc:~# cat /proc/tty/driver/serial
    serinfo:1.0 driver revision:
    0: uart:16550A mmio:0x01C42000 irq:25 membase 0xFEC42000 tx:0 rx:0
    1: uart:16550A mmio:0x01C20400 irq:53 membase 0xFED0C000 tx:0 rx:0
    2: uart:16550A mmio:0x01D0D000 irq:61 membase 0xFED0D000 tx:2141 rx:70 RTS|DTR
    root@epc:~# echo "test" > /dev/ttyS0
    root@epc:~# echo "test" > /dev/ttyS1
    root@epc:~# echo "test" > /dev/ttyS2
    test
    root@epc:~# cat /proc/tty/driver/serial
    serinfo:1.0 driver revision:
    0: uart:16550A mmio:0x01C42000 irq:25 membase 0xFEC42000 tx:6 rx:0
    1: uart:16550A mmio:0x01C20400 irq:53 membase 0xFED0C000 tx:6 rx:0
    2: uart:16550A mmio:0x01D0D000 irq:61 membase 0xFED0D000 tx:2808 rx:172 RTS|DTR
    root@epc:~#
     It seem that no errors in uart driver. i aslo change the pinmux of uart0 & uart1.

    as we known, uart0  multiplex  with i2c0 , uart1 multiplex with McASP0, so I change arch/arm/mach-da8xx/board-evm.c as follows:

    UART0:

    change :

    static const short evm_uart0_pins[] = {
      -1
    }
    to :
    static const short evm_uart0_pins[] = {
      DA8XX_UART0_RXD, DA8XX_UART0_TXD,
      -1
    }

    and  no use i2c 0

    static const short evm_i2c_pins[] = {
      -1
    }

    UART1:

    change :
     static const short evm_uart1_pins[] = {
      -1
    }
    to:
    static const short evm_uart1_pins[] = {
      DA8XX_UART1_RXD, DA8XX_UART1_TXD,
      -1
    }

    and no use  mcasp0

    static const short evm_mcasp0_pins[] = {
      -1
    }

     i  rebuild the kernel , it is no errer. I insmod a module  when system run up  to print  pinmux of system , The results are as follows:

    DA8XX : pinmux8   value 0x21111111
    DA8XX : pinmux11 value 0x11101122
     It means that no error on pinmux of uart0 & uart1, but  uart0 & uart1 are still no working .is that  anywhere also  need to be changed?

  • Hi Pen,

    me too had problems last weekend using UART1.

    Digging around with Lauterbach emulator I saw that EVM initialization code did not take off reset state for UARTs 0 & 1.

    For UART2 this seems to be done by UBOOT.

    Adding the following red code in board-evm.c file fixed the problem for UART1:

    static void __init da8xx_evm_map_io(void)
    {
     da8xx_evm_pinmux_override();
     da8xx_map_common_io();

     /* UART clock needs to be ready otherwise kgdbwait won't work */
     da8xx_uart_clk_init(DAVINCI_DA8XX_UART_CLK);
     da8xx_kgdb_init();

     /* Initialize the DA8XX EVM board settigs */
     da8xx_init_common_hw();
     da8xx_evm_psc_init();

     /* Enable UART1 power managment register PWREMU_MGMT (see SPUFM6.pdf pag. 38) */
     davinci_writel( (0x01 | (0x03 << 13)), DA8XX_UART1_BASE + 0x30 );

    }

     

    Hope this can help,

    PaoloC

     

  • Hello,

    In the document LSP2.2 Linux Drivers Datasheet (2009) page 46: 2.10.4 Constraints (UART), a very strage phrase exists :

    .....

    Following are the constraints of the driver:
    * Continuous UART input overruns under moderate load
    * Current driver software supports only UART2

    ......

    Is there anybody  knows what  does "Continuous UART input overruns under moderate load" mean,  because requests in  loops (periodic transmissions) encounter serious problems  in my applications, even with a simple loopback uart test dongle. My read(),write() functions got EAGAIN & EIO very often.  I think there is a bug in the driver but I dont know its hw nor sw problem.

     

    Ps: Things I have; omap l137evm rev E(spectrum digital) with XOMAP137AZKB3 & Montavista pro demo 5,

     

    Best Regards,

    Yetkin

     

     

  • Have you got any anwser on this yet?

    I'm trying to use UART1 on a OMAP-L138 Experimenters kit, and having the same problems. Seems to me that the driver is working, but there's no action on the actual pins :(

    One thing that I did was to enable to UART0 and UART1 in the kernel by removing the lines shutting down both UART1 andUART0 (in board-da850-evm.c):

        /*
         * shut down uart 0 and 1; they are not used on the board and
         * accessing them causes endless "too much work in irq53" messages
         * with arago fs
         */
    //    __raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
    //    __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);

    Any suggestions on how to solve this?

    /Jonas

  • If you are not getting answers to your questions here please post new topics to the Embbeded Software Forums: http://e2e.ti.com/support/embedded/default.aspx

  • hi pen:

          have you got your answer about this problem?

         I think that some modifications would be done in the file <da8xx_evm.h>:

     /*====================*/
    /* Serial Driver info */
    /*====================*/
    #define CFG_NS16550
    #define CFG_NS16550_SERIAL
    #define CFG_NS16550_REG_SIZE 4  /* NS16550 register size */
    #define CFG_NS16550_COM1 DAVINCI_UART2_BASE /* Base address of UART2 */
    #define CFG_NS16550_CLK clk_get(DAVINCI_UART2_CLKID) /* Input clock to NS16550 */
    #define CONFIG_CONS_INDEX 1   /* use UART0 for console */
    #define CONFIG_BAUDRATE  115200  /* Default baud rate */
    #define CFG_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }

    the default config for console is UART2, if it  transfer to be UART0 OR 1, it may work. I have not got the evm, so I can not  try it, And I wait for your response.

  • Hi,

    As I described earlier I had a similar problem to my OMAP-L138 Experimtenters board. Using echo "test" > /dev/ttyS1 I could see that the UART itself was working ok, but I could not get the data up to the app layer. 

    The problem was solved by changing the file system. Could be worth a try for you. I haven't investigated more deeply on what was the root cause.

    Jonas

  • Hi Jonas:

          Thank you for your quick response. Can you show the detail info about how to chang the file system(whos file system). Have you not done some modifications in the U-Boot file(except enabling the Uart0 & 1 and some in the pinmux reg)? I misunderstood.

  • Hi Jianwen,

    You'll find detailed instructions on how to set up a file system here: http://processors.wiki.ti.com/index.php/GSG:_Setting_up_OMAP-L1_Target_File_System

    Depending on which type of filesystem you are setting up you also need to modify the 'bootargs' in u-boot.

    Cheers,

    Jonas

  • Let the lines

    //        __raw_writel(0, IO_ADDRESS(DA8XX_UART1_BASE) + 0x30);
    //        __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);

    as they are. The comment "shut down uart 0 and 1 ..." is quite misleading.