Hi Claudio, On 03/09/2017 01:42 AM, Claudio Scordino wrote: > Hi Ralf, > > to answer your previous questions: > > stty -F /dev/ttyS0 > > reports a baudrate of 9600. And after enabling Jailhouse, 'stty -F /dev/ttyS0' will still report 9600, although the hypervisor reconfigured it to 115200 -> corrupt state in Linux.
(Just verified this with the qemu-vm demo.) > > Of course, issuing a > > stty -F /dev/(ttyS0 115200 > > before starting Jailhouse fixes the problem of the garbage on the console. And this is - in my opinion - the best solution to solve your issue, as Linux is aware of the device. Ralf > > 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 >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > > -- 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.
