Hi Ralf,

to answer your previous questions:

stty -F /dev/ttyS0

reports a baudrate of 9600.

Of course, issuing a

stty -F /dev/(ttyS0 115200

before starting Jailhouse fixes the problem of the garbage on the console.

We're running a Ubuntu 16.04 with kernel 4.4 on a i7.

Apparently, the console gets initialized to 9600 by the kernel or by
the hardware itself.

Best regards,

           Claudio


2017-03-09 10:24 GMT+01:00 Ralf Ramsauer <[email protected]>:
> On 03/09/2017 12:36 AM, Jan Kiszka wrote:
>> On 2017-03-09 09:30, Ralf Ramsauer wrote:
>>> On 03/08/2017 11:28 PM, Jan Kiszka wrote:
>>>> On 2017-03-09 02:07, Ralf Ramsauer wrote:
>>>>> Hi Claudio,
>>>>>
>>>>> On 03/08/2017 01:37 PM, Claudio Scordino wrote:
>>>>>> Hi Ralf,
>>>>>>
>>>>>> sorry, I didn't recall the discussion on list.
>>>>>>
>>>>>> Using the config currently generated by "jailhouse config create", our
>>>>>> i7 prints junk on the console, unless we manually add such divider.
>>>>>> If this is the intended behavior and we are supposed to add it, then I'm 
>>>>>> fine.
>>>>>> However, I'm afraid that several newbies could flood the list
>>>>>> complaining that their serial "doesn't work" if we don't properly
>>>>>> document such information.
>>>>> Usually we make the assumption that Linux initialises UARTs beforehand.
>>>>
>>>> We do this on ARM, we didn't do this on x86 prior to that commit as
>>>> Claudio pointed out.
>>>>
>>>> ARM is trickier to configure because we tend to have different dividers
>>>> on the different boards. For the x86 standard UARTs, we know the
>>>> divider, though. As long as the right value is applied,
>>>> re-initialization should cause no harm and will cover the case Linux is
>>>> configured to not use the UART at all.
>>> That's the point. As long as the 'right value' is applied. And if the
>>> right value is applied, nothing will happen and we can leave it out :)
>>>
>>> As Claudio received garbage on his serial line, I assume that the serial
>>> port was simply not configured with 115200 baud on Linux side before and
>>> as the UART is typically root-shared with Linux, enforcing 115200 baud
>>> in Jailhouse leads to corrupt settings in Root-Linux. If the divider
>>> would have been 0 (i.e., the device would not have been initialised at
>>> all), then he would not have received anything.
>>>
>>> By default, many distributions spawn a console on the serial line(s)
>>> that are configured with a baudrate different than 115200 (commonly
>>> 38400 or 9600). Better change those settings than overriding them.
>>
>> Hmm, my experience is that x86 distros leave the PC UARTs alone by
>> default, unless you tell them to use one. Which one does that differently?
> I have to admit that my experience is limited to ARM-based derivates,
> and they all tend to have the serial line enabled by default. And I
> guess that this applies to most x86-based dev-boards as well.
>
> Still, if you receive garbage on your serial line, then someone must
> have initialised it, otherwise you wouldn't receive anything. And I
> think it's better to not override a potentially running application that
> might have acquired the resource, as Jailhouse can not be aware of that
> with its limited knowledge.
>
> What happened to me once: On (Gentoo based) ARM-Linux, systemd spawns
> the console right *after* it received the first character and set the
> baudrate back to 38400. Pretty confusing, if this happens after you
> successfully started Jailhouse and saw its output, followed by garbage...
>>
>>>
>>> I understand the divider in the system config as an explicit setting
>>> that should only be used if the serial line is not handled by Linux,
>>> which could be detected by 'jailhouse config create'. And we have
>>> 'jailhouse console' that will work independent of the baudrate.
> BTW: This is exactly how Documentation/debug-output.md puts it:
> [...]
> A zero value means that the hypervisor will skip the initialisation of
> the UART console.  This is the case in most scenarios, as the
> hypervisor's UART console was initialised by Linux before.
> [...]
>>>
>>> I would rather suggest a FAQ and recommend to check the baudrate of the
>>> serial device before starting jailhouse than overriding Linux settings
>>> (by default).
> What about a FAQ "I see garbage on my serial console"?
>
> Serial garbage always has the misconfigured baudrate smell, no matter if
> we override Linux's settings or not..
>
>   Ralf
>>>
>>>   Ralf
>>>>
>>>> Jan
>>>>
>>>>> Setting the divider (or enabling clock gates) is as far as I understand
>>>>> (Jan, please correct me if I'm wrong) an optional feature that can be
>>>>> used, if the root cell doesn't properly setup UARTs (e.g., because it's
>>>>> missing the driver).
>>>>>
>>>>> What happens if you 'stty -F /dev/ttyS0 115200' before enabling
>>>>> jailhouse? Still garbage?  Or just 'stty -F /dev/ttyS0' to see what
>>>>> baudrate your device is currently set to before enabling Jailhouse.
>>>>>
>>>>> You told me off-list that you receive garbage on your serial line -- so
>>>>> I suppose the problem is that Linux set your baudrate just to something
>>>>> else than 115k2. Junk on the serial line is in almost all cases baudrate
>>>>> related.
>>>>>
>>>>>   Ralf
>>>>>>
>>>>>> Many thanks and best regards,
>>>>>>
>>>>>>            Claudio
>>>>>>
>>>>>> 2017-03-08 20:03 GMT+01:00 Ralf Ramsauer 
>>>>>> <[email protected]>:
>>>>>>> On 03/08/2017 07:55 AM, Jan Kiszka wrote:
>>>>>>>> On 2017-03-08 15:57, Claudio Scordino wrote:
>>>>>>>>> This patch fixes a regression introduced by commit
>>>>>>>>> 2a7c8733b6a3d47fb507eca4de5a33433199424c
>>>>>>>>> which by default does not initialize the UART divider to 0x1
>>>>>>>>> on the x86 platform.
>>>>>>> Isn't this intended behaviour? I remember that we had discussions on
>>>>>>> that on the list, and according to the commit message,
>>>>>>>
>>>>>>> ...
>>>>>>> If the divider is zero, the hypervisor will skip UART initialisation and
>>>>>>> assume that the UART was already initialised by Linux.
>>>>>>> ...
>>>>>>>
>>>>>>> All we do on x86 is to skip those four instructions if the divider is 
>>>>>>> zero:
>>>>>>> uart_reg_out(UART_LCR, UART_LCR_DLAB);
>>>>>>> uart_reg_out(UART_DLL, divider & 0xff);
>>>>>>> uart_reg_out(UART_DLM, (divider >> 8) & 0xff);
>>>>>>> uart_reg_out(UART_LCR, UART_LCR_8N1);
>>>>>>>
>>>>>>> which should in deed be done by Linux before, if this is what we define
>>>>>>> default behaviour.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Claudio Scordino <[email protected]>
>>>>>>>>> Signed-off-by: Michele Pes <[email protected]>
>>>>>>>>> ---
>>>>>>>>>  tools/root-cell-config.c.tmpl | 1 +
>>>>>>>>>  1 file changed, 1 insertion(+)
>>>>>>>>>
>>>>>>>>> diff --git a/tools/root-cell-config.c.tmpl 
>>>>>>>>> b/tools/root-cell-config.c.tmpl
>>>>>>>>> index 11956b7..a971f56 100644
>>>>>>>>> --- a/tools/root-cell-config.c.tmpl
>>>>>>>>> +++ b/tools/root-cell-config.c.tmpl
>>>>>>>>> @@ -62,6 +62,7 @@ struct {
>>>>>>>>>              },
>>>>>>>>>              .debug_console = {
>>>>>>>>>                      .address = 0x3f8,
>>>>>>>>> +                    .divider = 0x1,
>>>>>>> I'd rather insert this as a comment.
>>>>>>>>>                      .flags = JAILHOUSE_CON1_TYPE_UART_X86 |
>>>>>>>>>                               JAILHOUSE_CON1_FLAG_PIO |
>>>>>>>>>                               JAILHOUSE_CON2_TYPE_ROOTPAGE,
>>>>>>>>>
>>>>>>>>
>>>>>>>> We probably want this fixed for the in-tree x86 configs as well, namely
>>>>>>>>
>>>>>>>> configs/f2a88xm-hd3.c
>>>>>>>> configs/imb-a180.c
>>>>>>>> configs/qemu-vm.c
>>>>>>> Just tested qemu, on my VM everything works fine.
>>>>>>>
>>>>>>>   Ralf
>>>>>>>>
>>>>>>>> Ralf, am I right?
>>>>>>>>
>>>>>>>> Jan
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>



-- 
Claudio Scordino, Ph.D.
Project Manager - Funded research projects

Evidence Srl
Via Carducci 56
56010 S.Giuliano Terme - Pisa - Italy
Phone:  +39 050 99 11 224
Mobile: + 39 393 811 7491
Fax:   +39 050 99 10 812
http://www.evidence.eu.com

VISIT US AT EMBEDDED WORLD 2017 --- Hall 4 Stand 545

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to