Mity CPU Platforms » ARM9 Based QNX Platforms

Mark,

Which board are you using?
Are both uart0 and uart1 available?
Is u-boot using uart0?
Did you change the pinmux configuration to turn on uart0?
The boot script will also need to change to specify uart0 instead of uart1. Unfortunately, the console uart is specified in many places and all have to be changed.

Wow - thanks for the fast reply.
I do want to use UART0, I was just trying that to see if it was the problem.

I am running a 80-000297 MityDSP dev kit with a L138-FG-225-RC MityDSP L138F 456MHz module.

I am hooked up to the 10-pin header on the dev kit, which I believe is wired to UART1.
I believe UART2 goes to the RS-485 header.
Not sure where UART0 goes to.
I did not change the pinmux.

u-boot shows 1 serial port available
serial 80000003 SIO stdin stdout stderr

If you are seeing the Welcome banner, you should be through the start-up code and into the qnx kernel. By default, the boot script looks something like this:

        #######################################################################
        ## Create a symbolic link for the file /usr/lib/ldqnx.so.2
        #######################################################################
    procmgr_symlink ../../proc/boot/libc.so.3 /usr/lib/ldqnx.so.2

        #######################################################################
        ## Give the Welcome message
        #######################################################################
    display_msg Welcome to QNX Neutrino 6.5 on the Critical Link MityDSP OMAPL138 Board

    #######################################################################
    ## SERIAL driver (UART x)
    ## uncomment the appropriate line depending on which uart is being used.
    ## Differences are with the base address and irq number.
    ## assumes pin mux is setup correctly. (see init_hwinfo.c in startup code)
    #######################################################################
    # Uart0
    # devc-ser8250 -e -F -S -b115200 -c150000000/16 0x01c42000^2,25
    # Uart1
    devc-ser8250 -e -F -S -b115200 -c150000000/16 0x01d0c000^2,53
    # Uart2
    # devc-ser8250 -e -F -S -b115200 -c150000000/16 0x01d0d000^2,61
    waitfor /dev/ser1
    reopen /dev/ser1

    slogger
        pipe

    #######################################################################
    ## Create any extra uart devices. Uncomment as needed.
    #######################################################################
    # Uart0
    # devc-ser8250 -u2 -e -F -S -b115200 -c150000000/16 0x01c42000^2,25
    # waitfor /dev/ser2
    # Uart1
    # devc-ser8250 -u3 -e -F -S -b115200 -c150000000/16 0x01d0c000^2,53
    # waitfor /dev/ser3
    # Uart2
    # devc-ser8250 -u4 -e -F -S -b115200 -c150000000/16 0x01d0d000^2,61
    # waitfor /dev/ser4

    #######################################################################
    ## I2C driver
    #######################################################################
    display_msg Starting I2C0 Services

If you are not seeing the "Starting I2C0 Services" message, then it must be stuck in the waitfor /dev/ser1. You could try putting in more display_msg lines to verify this.

Have you made changes to the boot script?

It might be useful to print out the system page. You could try the command: "pidin -syspage" before the devc-ser8250 line in the boot script. It looks like the uart is working (probably left-over from u-boot and the startup code) and then has problem in the kernel initialization. I have not seen a problem like this before unless somehow the different initializations are not all trying to do the same thing. (e.g. startup code uses one uart but boot script uses something else)

Hope this helps.

I am currently running an unmodified boot script, the above section matches.

A log message immediately after

# Uart1
devc-ser8250 -e -F -S -b115200 -c150000000/16 0x01d0c000^2,53

pidin syspage returned the text in the attached file

...one more thing... Linux boots up fine, and reports:

Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0x1c42000 (irq = 25) is a 16550A
serial8250.0: ttyS1 at MMIO 0x1d0c000 (irq = 53) is a 16550A
console [ttyS1] enabled
serial8250.0: ttyS2 at MMIO 0x1d0d000 (irq = 61) is a 16550A

Mark,

It has been a little while and I wanted you to know that we have reproduced this problem and are working on a fix.

Great, thanks.
FWIW I've verified USB and Ethernet works fine. I can comment out all the ports and run from the serial port as setup by u-boot, and I can telnet in too.

Mark,

A new BSP has been posted. The serial port driver has been changed so that with a -M option, it will not enable the modem state interrupt. For some reason, on the newer revision board/module, there are a lot of these interrupts and when enabled, it caused problems. If you start with a new BSP import, the -M changes are automatic. If you just unzip the files over your existing files, then you will need to manually change the .bsh file to add the -M option to the devc-ser8250 lines.

The new BSP also includes support for changing the processor speed to 456MHz. See the wiki page for instructions on how to make use of this.

Hope this helps.

Confirmed serial works - thanks.