Setting Data/Stop/Parity Bits on Serial Port in Guest OS

[kevin_sikorski]

I'm working on a T1040 based system, and I'm exposing a hardware serial port to a Guest OS (through the hardware hypervisor).  The serial port appears as /dev/tty/EHV1, and I can send and receive data through it.  But I can't seem to set the baud rate, data bits, stop bits, or parity on that port.  If I run my OS bare metal, I can set the data bits, stop bits, and parity, but I still can't set the baud rate without altering the device tree and setting the "current-speed" property to set the default baud rate. I'm testing this with:

   stty -F /dev/ttyHV1 cs5      or

   stty -F /dev/ttyHV1 9600

This is actually my second serial port.  My first is set up as the console mux.  This also sends and receives data correctly, but suffers from the same inability to set connection parameters on it. 

My best guess is that something is wrong in my device tree, but I don't see any clear causes.

My non-mux serial port is set up in the guest device tree like:

hv: hypervisor-config {

...

serial1: serial1 {
device = "serial1";
};

...

}

part1: part1 {

compatible = "partition";

...

byte-channel0 {

compatible = "byte-channel";
endpoint = <&serial1>;

};

serial1 {
device = "serial1";

};

}

Where I have an alias set up in the host hardware device tree like:
aliases {

serial1 = "/soc@ffe000000/serial@11c600";

}

Does anyone have any suggestions on what could be wrong, either in my device tree or elsewhere?  Or, would anyone have an example device tree where they have given a guest OS full access to a serial port (ie, can both send/receive data and change connection parameters)?

Thanks

[bpe]

Below is the response of the development team:

Currently, hv hardcodes the serial configuration, a proper approach would be to add support in the hypervisor to configure the serial line parameters. Please note that this would involve significant development and testing effort. Since there is a workaround for this issue, we have no plan to take great effort for this better-to-have feature.

Regards,

Platon

[kevin_sikorski]

Thanks for the feedback, it's good to have a final, conclusive answer.

[bpe]

To summarize the scenario: You link a byte channel
with an UART in the hv config file, the guest Linux kernel boots up
and probes the byte channel driver, then you try to set
serial line parameters, such as speed through ioctl()s to the byte
channel driver.

The byte channels are para-virtualized devices,
thus trying to set serial line parameters such as speed does not
make sense.

Some questions to clarify:

• Do you expect that a byte channel linked to a real UART to be configurable
  for as a real UART through the byte channel driver?
• Can you please share the full hypervisor log, kernel log and hv config file?
• Have you tried seting the baud rate from the device tree?  The relevant property is "current-speed", see here for documentation:
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bin...

[kevin_sikorski]

As for byte channels - I'd be perfectly happy not using them.  Is there an example DTB that does what I'm looking for? 

And unfortunately, I can't publicly post the config file since it is proprietary.  

My basic goal is to allow my guest OS to have "full" control over a single serial port - the ability to transmit and receive data, as well as set baud rate, stop bits, data bits, and parity - that would be the satisfying long-term answer.  A less satisfying solution would be to hardcode the needed values in the DTB, such as using current-speed to set baud - and that works, but just for baud rate.  I haven't seen any properties in the DTB documentation to default the serial port to another data bits/parity/stop bits setting.  The guest OS will be communicating with other hardware that isn't 8N1, so relying on those defaults won't work for this application.

I'm concerned about the serial ports using DUARTS - I've seen some bit of documentation that make me think that I can't use a serial console mux to communicate with my guest OSes and the hypervisor, and the remaining serial port on that same DUART in a guest OS as a normal serial port.  For example, page 2150 of the QorIQ manual says:
    In a typical configuration one DUART is allocated to the hypervisor for console and byte-channel services. Any remaining DUARTs are available for direct assignment to a partition.

If I have only one DUART, can I use one serial port on that DUART for a serial console mux via the hypervisor, and let the guest control the other serial port?

Thanks for your input!

[bpe]

There is an Applications team involved in the discussion of this issue, their comments are below inline:

As for byte channels - I'd be perfectly happy not using them.  Is
there an example DTB that does what I'm looking for?

 My basic goal is to allow my guest OS to have "full" control over
a single serial port - the ability to transmit and receive data, as
well as set baud rate, stop bits, data bits, and parity - that
would be the satisfying long-term answer.  

This can easily be achieved by directly assigning the UART to the guest.

A less satisfying solution would be to hardcode the needed values in the DTB, such as using current-speed to set baud - and that works, but just for baud rate.  I haven't seen any properties in the DTB documentation to default the serial port to another data bits/parity/stop bits setting.  The guest OS will be communicating with other hardware that isn't 8N1, so relying on those defaults won't work for this application.

True, only speed is configurable through DTS.

If I have only one DUART, can I use one serial port on that DUART for a serial console mux via the hypervisor, and let the guest control the other serial port?

Since the two serial ports share the interrupt, it's unfortunately impossible to share a single DUART between a guest and hypervisor.
Is this usage of a single DUART a strict requirement for your design?

[kevin_sikorski]

My understanding of the t1040 is that it has two DUARTS.  Currently, the only ports I have physical access to are on that same DUART.  I'm talking with people here to see if a hardware change is possible to grant me access to ports on the other DUART.  

If I can't access the other DUART for some reason, are you aware of any other options I may have? Or are hardware solutions my only option.

Thanks