Using PTY as a proxy for remote serial port - linux

I'm working on an IO expansion device.
Among other things, it exposes a bunch of serial ports, which I want to expose on my Linux host as /dev/ttySomethingN
I could write a TTY kernel module for that, but I'd like to keep it on userspace for now.
The solution I've found is to use a PTY as a proxy: The master side talks to my device and the slave talks to my applications, and I use TIOCPKT_IOCTL to know when the device needs to reconfigure its speed/bits/parity/stop bits.
It works pretty well! See my source
But there is one little issue: I cannot set the number of bits (CS5/CS6/CS7) or parity (PARENB) in a PTY:
Any ideas why this restriction is in place? And how to work around it?

Related

QEMU: USART communication between two MCUs (STM32)

I try to create two qemu instances and let them communicate via usart. the background is, that I want to emulate the communication while the boards aren't even finished but the code is already testable.
So the creating of two parallel qemu instances is no problem, but the communication between these two doesn't happen.
The way I thought it maybe could work is to extend the command line of the master device with -serial pty to bind the USART1 of the STM32 to an pty socket and after that binding the USART1 of the slave to the same pty. But obviously it doesn't work.
The code I use is already tested with two Olimex development boards so there have to be problems in the qemu setup.
Does anyone have tried something like this or can provide a different way to establish an emulated connection?
Use semihosting with unix pipes. I have implemented this approach and it works well. Only drawback is that there is no way in the semihosting spec to configure a file descriptor to be async, so it will always block when you do a read.

Using gdbserver on remote device w/ a single serial connection?

I'm debugging an embedded application that runs in a Linux environment on a remote target. The only usable interface to the board is a single serial interface. Right now that's hooked up /bin/sh on init. I'm connecting with minicom, (re-)loading my application with lrzsz, and using printfs to get the job done.
I'd like to use gdbserver for more fine-grained debugging, but connectivity seems like a problem. Normally I'd connect over ethernet, but that's not available on this hardware. I understand gdbserver can run on a serial line, but right now my one comm port belongs to the shell.
Is there a good way to work around this restriction? Ideally I'd like to be able to run gdbserver and get back to a shell when I'm finished. I've tried starting gdbserver from the shell using the one available serial interface (/dev/ttyS0), then quitting minicom and starting GDB on my host, but it's messy & doesn't appear to work (even after setting remotebaud appropriately). Should that work? What's the sane thing to do in this situation?
How about the old-school solution? Use PPP to run IP networking over your serial line. You can then ssh (or even telnet) to your board, and connect to gdb at the same time. Given your circumstance, I'd recommend starting pppd manually to reduce the risk of locking yourself out through misconfiguration. The LDP link dates from 2000, but contains a lot of debugging advice.

Implementing a kernel debugging module for a Linux guest OS inside a VmWare VM

Sorry for the rather long post.
I need some input regarding a project that I am going to undertake.
I am trying to make an application that collects kernel debugging information from a guest Linux OS, located inside a VmWare Virtual Machine, and send them to a host OS efficiently.
So far, I have found a similar project, but written for Windows[1].
The author of the project wrote a DLL that is loaded into memory, and replaces the implementation of the KdSendPacket and KdReceivePacket functions, to use the VmWare GuestRpc[2] mechanism, instead of the slow serial port.
The data are then send to a debugging application on the host(Kd or WinDbg) trough a named pipe.
The author claims that there is a speed-up up to 45%, by avoiding the serial port transmission.
I am trying to achieve something similar ,but for Linux, and try to make the debugging process a little faster, than using the serial port.
My concrete questions are :
Do any similar applications exist?
I didn't manage to find any.
Would such an application be worth it ,comparing its functionality to netconsole[3], for example?
What method of intercepting printk messages would you suggest ?
Is there an equivalent of KdSendPacket/KdReceivePacket on Linux ?
[1]. http://virtualkd.sysprogs.org/dox/operation.html
[2]. http://articles.sysprogs.org/kdvmware/guestrpc.shtml
[3]. http://www.kernel.org/doc/Documentation/networking/netconsole.txt
Using the serial port is really suboptimal.. even the (virtual) network would be preferable to that, but getting back to host-guest IPC channels, VMware's VMCI comes to mind.
many approaches can use to achieve your goal, below methods can be applied if network is connected:
use syslog service and transfer log though network to your server:
syslogd, syslogng seems support sending log to a log server with some filter critiera.
directly call tcp/udp socket functions in your kernel module to sends your collected data back to server.
other approaches, you may write application on host machine that calls hypervisor's share memory access function to read the memory buffer of your kernel module. However, the xen/kvm hypervisor both support these apis and i am not sure about weather vmware have this kind of library.

Access GPIO on atom board

On this machine: http://www.nexcom.com/ProductModel.aspx?id=376f4fa5-64f3-41d1-afba-60ee48883465
I'm trying to access gpio, but neither Nexcom or Intel support has been very helpful.
The closest I've come is this blog post which says I have to write my own driver: http://geekswithblogs.net/BruceEitman/archive/2010/08/01/windows-ce-using-a-driver-to-readwrite-hardware-registers.aspx
From the nexcom manual it states gpio port is located at 0EE4H (0xEE4). What am I supposed to with this info? Am I really supposed to write my own driver?
edit: is must work on windows xp embedded and windows 7 embedded.
You can't directly access hardware resources (like GPIO pins) from userspace processes unless there's a driver that exposes this functionality. This means that either you find a suitable driver (I have no clue about where to look for such a thing) or you write your own.
p.s. It may also be the case that your OS expose the GPIO pins somewhere. On a linux prototyping board I worked on once there were a few files (IIRC /dev/gpioX, with X being the number of the pin) you could read/write to if you had the appropriate permissions.
You need GIVEIO.SYS.
It actually comes from Microsoft originally.
when you install it, you specify what port addresses you want.
then the user space program can access the ports directly.
You unix bretheren can just call ioperm() instead with the process running as a root. A shame MS didn't do that, but GIVEIO.SYS is okay.

Get two Linux (virtual) boxes talking over a serial port

What is the best way to setup one Linux box to listen on its serial port for incoming connections? I've done a lot of googling but I can't find the right combination of commands to actually get them to talk!
My main objective is to provide a serial interface to running instances of kvm/qemu VMs. They currently only have a VNC interface (they are on headless servers, no X). I can get the VM to create a serial device by starting it with the -serial file: flag, but how to talk to it, is a whole other problem. Both boxes are running Ubuntu 8.04.
The Linux Serial HOWTO has a lot of detailed information about serial communication in general. The more-specific Linux Remote Serial Console HOWTO is what you're really looking for if you want to be able to log into your virtualized systems using the serial port as if you were at the console. As Hein indicated, you'll need a null modem cable and need to run minicom on the remote terminal.
The Linux console is used in two ways, each of which must be configured separately for serial use. You can configure the kernel to copy its messages over the serial port, which is occasionally interesting for watching the system boot and nearly indispensable if you're doing kernel debugging. (This requires kernel support and updating the boot parameters so the kernel knows you want serial output; see chapter 5 of the second howto.) You're probably more interested in logging in via the serial port, which requires running getty on the serial port after boot (just like your system already runs getty on the virtual terminals after boot), which is described in detail in chapter 6 of the howto.
I assume you connect the two serial ports using a "null modem" cable.
Use a program like minicom to talk to remote system -- you probably need to set up the communication parameters and possibly turn off hardware flow control (if your cable doesn't have the flow-control lines connected).
Say you're doing this on /dev/tty1.
in the shell
chown *youruser* /dev/tty1
then in a Perl script called example.pl
open PORT, "</dev/tty1" || die "Can't open port: $!";
while (defined ($_ = <PORT>))
{
do_something($_);
}
close PORT;
Obviously there is more to do if you want this to start automatically, and respawn on error, and so on. But the basic idea is to read from the serial port like a file.

Resources