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

[Paul Skentzos <paul.skentzos@xxxxxxxxxxxxxxx>]

Hi Luke,

On 10/7/2015 10:15 AM, Luke Dunstan wrote:
> Hi Paul,
> 
> Did you get serial ports working even in dom0 on Cubietruck yet? It took me
> quite a while to discover that Xen normally disables the A20 UARTs by deleting
> them from the device tree:
> 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/platforms/sunxi.c;h=0ba7b3d9b476a95edb653e120b7b3900a47f7c06;hb=HEAD#l64
> 
> Luke
> 

Yes, we do have this working. It was a bit of an annoyance that we discovered
just as you did when starting to work on the Cubietruck.

We found that all serial ports with the "snps,dw-apb-uart" driver are
blacklisted on the "sunxi" platform to prevent dom0 from having driver access to
the Xen console.  So we hacked up the attached patch.  Which is not an ideal
fix, but it was good enough for now.

The better fix would be to have Xen compare the memory address for every item in
the device tree against the addresses that Xen has already reserved for itself.

- Paul

> 
> On Wed, 7 Oct 2015 at 21:00 Paul Skentzos <paul.skentzos@xxxxxxxxxxxxxxx
> <mailto:paul.skentzos@xxxxxxxxxxxxxxx>> wrote:
> 
>     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>
>     > <mailto: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>
>     <mailto: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 
> <mailto:MirageOS-devel@xxxxxxxxxxxxxxxxxxxx>
>     http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>

Attachment: 0001-Fix-blacklist-for-Cubie-UARTs.patch
Description: Text document

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