Re: [MirageOS-devel] Writing to Multiple Serial Ports

[Paul Skentzos <paul.skentzos@xxxxxxxxxxxxxxx>]

Dave,


On 10/6/2015 5:04 PM, David Scott wrote:
> Hi Paul, Aaron,
> 
> On Tue, Oct 6, 2015 at 8:27 PM, Paul Skentzos <paul.skentzos@xxxxxxxxxxxxxxx
> <mailto:paul.skentzos@xxxxxxxxxxxxxxx>> wrote:
> 
>     We are trying to access a serial port passed to a domu. We're very new to 
> Mirage
>     and ocaml, but plan on converting our existing system to use MirageOS for
>     various domU's.
> 
>     So, at the moment, the question we have is whether anyone has had any 
> success
>     writing to multiple serial ports with one of those serial ports being 
> accessed
>     from a domu?
> 
>     As a first attempt, we took the Mirage console example and added a second
>     console. We connected it to '1' and then to /dev/null and tried to print 
> to it.
>     Neither of the ideas were valid. We're not sure what the console should 
> be named
>     or what the hashtbl is looking for. The application compiles, but the VM 
> halts
>     with a message stating. "... waiting for hotplug". The application built 
> for
>     unix didn't work either.
> 
> 
>     We are trying to read data from a GPS receiver from a domu.
> 
> 
> Interesting! Is the GPS receiver connected to a physical serial port on the 
> host?
> 

Thanks for the quick response. Yes, the GPS is connected to the host, to a
hardware serial port.

> The virtual serial ports that Mirage can see need to be served by something on
> the host (a "backend", typically in dom0). If you're creating your VM with "xl
> create" then you can declare "channels"[1] which will spawn a qemu process in
> dom0 which will act as the server/backend. At the moment the backend can only 
> be
> connected to a fresh tty or a Unix domain socket -- there is no built-in 
> support
> for proxying to a real /dev/ttyS* device.
> 
> I think the first thing to do is to verify that adding a 'channel' to your xl
> config file causes the Xen domU to get further than "waiting for hotplug". 
> After
> that I think you could declare the backend to be a Unix domain socket, and 
> then
> run a proxy in dom0 which would write the data to the appropriate ttyS device.
> 
> Sorry that's a bit clunky -- when I added the channel support to "xl" I didn't
> think about the possibility of a real serial port. I'm sure that could be 
> added
> in future though.
> 
> What do you think?
> 

This is really good information and you were speaking the language my colleague
and I were as we iterated through the design.

Here are our results. Running the system on an x86 VM worked just as you
described above, so that was great news. However, and we should have been clear
about this at the beginning, our hardware platform is ARM based; Cubietruck,
specifically. We tried the same process on the Cubietruck and it did not work.
I'm assuming that this is the case since ARM does not make use of qemu like x86
does.

It seems that this could be overcome on ARM, however not without some
difficulty. Any thoughts on this?

Best regards,
Paul


> Cheers,
> Dave Scott
> 
> [1] http://xenbits.xen.org/docs/unstable/misc/channel.txt
> 
> 
>     Any ideas where we should look for getting this capability?
> 
>     I appreciate the help!
> 
>     Paul Skentzos
>     Aaron Cornelius
> 
> 
> 
> 
> 
>     _______________________________________________
>     MirageOS-devel mailing list
>     MirageOS-devel@xxxxxxxxxxxxxxxxxxxx 
> <mailto:MirageOS-devel@xxxxxxxxxxxxxxxxxxxx>
>     http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
> 
> 
> 
> 
> -- 
> Dave Scott

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel