We are working on porting QNX to a custom ARM Cortex A7 board. We are facing trouble while launching the serial driver through the build script.
In the build script we launch the driver with the following command devc-pl011Uart -e -S -F -b115200 -c51200000 -u3 0x50020000,59
waitfor /dev/ser3
reopen /dev/ser3
display_msg Reopen done
The reopen command succeeds and we get the display print on console.
There after the shell hangs indefinitely and does not execute any shell commands correctly.
We observe from JTAG debugger that we consistently get Receive interrupts whenever we input something from the host and the input is processed by tty
to be echoed back on console. However the given input is not processed by the shell.
Do we need to enable/configure something specific in Startup, Build script to enable the TTY layer to work consistently.
Can somebody please help in resolving this issue.
Yes we are trying to use the serial port to enter commands to the shell.
Below are the set of observations.
On board power on i see the following logs on console.
[i][b]Loading IFS…done
alloc_syspage_memory: syspage size:000008c8 _syspage_ptr:a079a000
callout_io_map: mapping paddr:48e01000 returns:fc405000
callout_io_map: mapping paddr:48e02000 returns:fc406000
callout_io_map: mapping paddr:50020000 returns:fc408000
callout_io_map: mapping paddr:50020000 returns:fc409000
callout_io_map: mapping paddr:50020000 returns:fc40a000
System page at phys:a079a000 user:fc404000 kern:fc404000
Starting next program at vfe05e02c
cpu_startnext: cpu0 → fe05e02c
Welcome to QNX Neutrino 6.6.0
slog launched
pipe launched
Serial Driver Launching…
Reopen done
[/b][/i]
The Shell on bootup hangs at this point. I get the prompt only if i enter Ctrl+C character.
Once i get the prompt i am able to enter characters but the shell does not process them Instead i see the same input being printed twice on console.
###########################################################################
[image=0xA0000000]
[+keeplinked]
[virtual=armle-v7,raw] .bootstrap = {
# Options specific to this BSP:
# Increase or decrease the verbosity level
startup -v
#######################################################################
## PATH set here is the safe path for executables.
## LD_LIBRARY_PATH set here is the safe path for libraries.
## i.e. These are the paths searched by setuid/setgid binaries.
## (confstr(_CS_PATH…) and confstr(_CS_LIBPATH…))
#######################################################################
We are using TeraTerm at the host machine with the following line configuration 115200 8-N-1.
The serial port on board is a Serial over USB using FTDI chip connected to a ARM PL011 UART IP.
We are able to observe the following through the debugger.
On entering a character on console Rx Interrupt is triggered.
The Rx handler passes the input character to TTY layer via tti call.
The TTY layer processes it and echoes it back through tto call. (This is confirmed by the character appearing on console.)
However when we press Enter after entering a command the characters previously entered are echoed back again through a call to tto.
We are unable to figure out why the call to tto happens again and who calls it.
I wonder if you just need to set your terminal type directly on the serial port. This talks about terminal types over serial qnx.com/developers/docs/6.3. … /char.html
If you add the ‘stty’ command to your build image you can run it and see what mode your in.
stty </dev/ser3
Alternatively you can just try and set it and hope that’s the problem.
stty term=qansi </dev/ser3
You may also need to adjust the options you are passing to your serial driver.
I could be wrong about this, but it seems like you are assuming that the boot script is being processed by an “sh” shell. I don’t think this is the case. Typically what I’ve seen to accomplish what you want is something like this.
Thanks for your help so far.
To run the stty i need the shell to accept the commands which is not the case here.
Maschoen,
Thanks for your help the change from ksh to esh helped us progress.
If we change the shell to esh i get the shell prompt.
I made the following change to my build script. [+session] PATH=/proc/boot esh &
With the above changes i am able to launch the shell, but the shell is very slow it takes about a minute for any command to execute.
Some control characters like backspace still don’t work.
I am a little curious about this change how does changing to esh alter the behavior so much. http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/utilities/e/esh.html says it is for memory constrained systems.
Some of the reference BSPs i referred like beaglebone use the ksh to launch their shell.
The fact that is works but is slow suggests contention. Put pidin in the image and run it. Look for processes that are in READY mode, especially those at or the same or higher priority than esh. You could also try to bump esh to a higher priority to see if that helps.
If something is running free (in READY mode all the time) that could be a problem.
I was able to resolve the issue of slow command response to shell commands.
The issue was in my tto function where the exit condition for transmission of characters was incorrect.
With this fix we are able to launch the shell and execute commands by launching esh from the build script.
Some small issues still exist like for instance the TAB command does not work.
The shell works fine only if we use the esh if we use the ksh we are unable to launch the shell.
Do we need to set some path or environment variable in the build script to launch the ksh?
I have tried with ksh -i & option but no luck the behavior is still the same.
If i launch the esh -i & the shell is launched and the commands are processed.
But the following commands like Ctrl-Z and TAB do not work.
On entering Ctrl-Z to stop a process the shell hangs indefinitely(but Ctrl-C works fine when used to stop a process) and TAB does not throw any help with commands.
Is it something to do with terminal type?
Are there any limitations with using esh with respect to some commands like CTRL-Z, TAB.
echo $TERM
qansi
echo $SYSNAME
nto
echo $SHELL
/bin/sh
Below is the stty output. #stty -a
Name: /dev/ser3
Type: serial
Opens: 2
CTRL-Z hanging the shell is expected behavior. This happens with ksh too. What really happens is that the shell exits and control passes back to your build file. There is nothing more to run in that file so it hangs.
So instead of starting a shell in your build file you start tinit which runs forever and will launch shells for you (note you have to put your custom ttys file in your build and provide a path to it. In that ttys file you replace the /bin/login shown in the docs with /proc/boot/ksh).
On the shell prompt if we press Ctrl-Z or a Ctrl-C nothing happens the shell does not process these inputs.
When we use this to send a signal to a process like a ping command the behavior is different for a Ctrl-C and Ctrl-Z.
For Ctrl-C the ping stops and for Ctrl-Z the shell hangs.
We have a QNX x86 Virtual machine image running on windows host, on this system both the Ctrl-C and Ctrl-Z can be used to stop a process.
So we were trying to match the behavior of the esh shell with what we are observing with the virtual machine image.
One more observation is that if we don’t launch the uart serial driver from the build script the ksh is getting launched.
The ksh during launch gives the following error
ksh: No controlling tty (open /dev/tty: No such device or address)
ksh: warning: won’t have full job control
With the ksh launched we can run all the commands but we cannot stop/signal any running processes.(No job control)
It is only when we launch our serial driver the ksh hangs and strangely enough only the esh is works with the serial driver.
I’d need to see the build script for the virtual machine and compare it with the one you are using on your system to be able to make some sense out of what is different. One obvious difference is the virtual machine is using a regular keyboard console for input and your trying to use a keyboard over serial for input.
It’s possible the serial driver itself could be changing the behavior of CTRL-C/CTRL-Z. Do you have any documentation for how it works?
How do you know that ksh isn’t being launched when you run your uart serial driver? Maybe it’s not printing out any error messages.
In any case I’d focus on using tinit. As long as you aren’t really memory constrained it’s the better way to go (it’s what we use) because it relaunches shells automatically.
The table in this link says that command and filename completion feature is not supported on esh and only the ksh supports these features. qnx.com/developers/docs/660/ … Shell.html
We need to launch the ksh to support all the features of the shell.
Only flow control features are not supported yet, does this make a difference in launching different shells considering the same driver is able to launch esh but not the ksh.
Assuming it is, do you see this message printed with esh and ksh? That’s the last printout before you launch the shell
‘MTU driver launched’
Also I don’t see where you assign the shell to the serial port like you did originally in the first post of your build file. That sets the console input/output to serial port #3 which is where I assume you’ve hooked up your keyboard.
[type=link] /dev/console=/dev/ser3
Lastly ksh is much more complex than esh. It’s meant to be used with user accounts, configuration files etc. Maybe it can’t work without them.
You should be able to remove the stuff you don’t need (USB/network etc) and substitute in your serial driver/BSP stuff etc and get this to work assuming serial port 1 as in this example.
display_msg Welcome to QNX Neutrino 6.x on the Malta evaluation board
#######################################################################
## SERIAL driver
#######################################################################
devc-ser8250 -e -c1843200 -b38400 0x180003f8,0x80020004 \
slogger &
pipe &
#######################################################################
## PCI server
#######################################################################
display_msg Starting PCI server...
pci-malta &
waitfor /dev/pci 4
#######################################################################
## FLASH driver
#######################################################################
# display_msg Starting flash driver...
#
# devf-malta &
#######################################################################
## NETWORK driver
## - substitute your IP address for 1.2.3.4
#######################################################################
display_msg Starting on-board ethernet with large TCP/IP stack...
io-net -dpcnet -ptcpip
waitfor /dev/io-net/en0 4
ifconfig en0 1.2.3.4
#######################################################################
## REMOTE_DEBUG (gdb or Momentics)
## - refer to the help documentation for the gdb, qconn and the IDE
## for more information on remote debugging
## - the commands shown require that NETWORK is enabled too
#######################################################################
# devc-pty &
# waitfor /dev/ptyp0 4
# qconn port=8000
#######################################################################
## USB driver
#######################################################################
# display_msg Starting USB driver...
#
# io-usb -duhci &
# waitfor /dev/io-usb/io-usb 4
#######################################################################
## These env variables are inherited by all the programs which follow
#######################################################################
SYSNAME=nto
TERM=qansi
PATH=:/proc/boot:/bin:/sbin:/usr/bin:/usr/sbin
LD_LIBRARY_PATH=:/proc/boot:/lib:/usr/lib:/lib/dll
#######################################################################
## NFS_REMOTE_FILESYSTEM
## - This section is dependent on the NETWORK driver
## - Don't forget to properly configure and run the nfsd daemon on the
## remote fileserver.
## - substitute the hostname or IP address of your NFS server for
## nfs_server. The server must be exporting
## "/usr/qnx630/target/qnx6/mipsle".
#######################################################################
display_msg Mounting NFS filesystem...
waitfor /dev/socket 4
fs-nfs3 nfs_server:/usr/qnx630/target/qnx6/mipsle /mnt
[+session] ksh &
We were able to solve the issue of launching the ksh with the serial driver.
The problem was in one of the functions in the driver named drain_check.
In this function we were checking the FIFO empty condition against a wrong register bit because of which the shell was getting stuck in a indefinite loop.
During debug we found that this function affects the working of ksh only and does not impact the working of esh, because of which we were able to launch the esh and not ksh. With this change in the driver all the features of the shell including command completion and job control work fine.
Thanks for your support throughout it helped us make progress when we were having little clue on how to progress with this problem.