On 23.07.19 19:53, Ralf Ramsauer wrote: > > > On 7/23/19 7:21 PM, Jan Kiszka wrote: >> On 23.07.19 18:38, Ralf Ramsauer wrote: >>> >>> >>> On 7/23/19 5:35 PM, Jan Kiszka wrote: >>>> On 23.07.19 17:19, Jan Kiszka wrote: >>>>> On 23.07.19 16:50, Ralf Ramsauer wrote: >>>>>> Two bad news: Linux's 8250 driver needs patching. At least we need some >>>>>> parameter like 8250.platform=disable to disable the probing for platform >>>>>> uarts. Why? >>>>>> >>>>>> ATM, we must specify 8250.nr_uarts. Otherwise the kernel will touch >>>>>> restricted ports. It does touch those ports, as it lacks ACPI platform >>>>>> information and assumes 'any' platform UART is present. >>>>> >>>>> Yes, nr_uarts is the patch-free approach for now. I once had a hack that >>>>> propagated the information "this is Jailhouse, you may not find platform >>>>> UARTs" >>>>> to the driver. But that was a hack, so I didn't propose that upstream >>>>> along with >>>>> the other x86 changes. Plus, there are cases where we do want to use a >>>>> platform >>>>> uart in the non-root cell. >>>>> >>>>>> >>>>>> I.e.: >>>>>> 8250.nr_uarts=1 only touches 0x3f8 >>>>>> 8250.nr_uarts=2 touches 0x3f8 and 0x2f8 >>>>>> 8250.nr_uarts=3 touches 0x3f8, 0x2f8, 0x3e9 (?) >>>>>> >>>>>> In addition to that I have a PCI device. And Linux won't probe it until >>>>>> it probed all other PIO ports. If I specify 8250.nr_uarts=1 (as I do >>>>>> want to restrict access to 0x2f8), it will never probe the PCI device. >>>>>> >>>>>> So at the moment, the hack is to set 8250.nr_uarts=4 and permit access >>>>>> to all ports. Yikes. At least I now know that the PCI device basically >>>>>> works, but still, this needs to be patched. >>>>>> >>>>> >>>>> OK, that was probably not yet addressed. We once had a setup with UARTs >>>>> on a PCI >>>>> card, but that machine also had no platform UARTs IIRC. >>>>> >>>>> If there no other way to tell Linux the number of platform UARTs, we will >>>>> have >>>>> to introduce one, for the sake of this use case already. >>>>> >>>> >>>> Maybe we can do something like arch/x86/platform/ce4100/ce4100.c to "tune" >>>> the >>> >>> Thanks for the pointer. >>> >>>> platform UARTs (ce4100_serial_fixup). But it still takes an extension of >>>> the >>>> boot protocol to provide Linux with the information about available >>>> platform UARTs. >>> >>> Hm. We do have the comm region... It will hold the config's struct >>> jailhouse_console. We could use this in combination with >>> serial8250_set_isa_configurator. >>> >>> This won't enable all platform uarts, but with this we could >>> automatically enable at least one platform uart + hypervisor debug >>> output. This should be sufficient for most cases. >> >> This is x86 only: If the well-known legacy ports are open in the config and >> also >> the related IRQs, cell-linux could set some to-be-defined flags in the > > Hmm. The config (as well as the comm region) lacks the IRQs of the > platform UART. But they should be static for platform UARTs afaict.
The config has this: irqchip at standard address 0xfec00000, pins 3 & 4. If set, then the UART is passed. The comm region is not needed here, the setup_data is filled by the loader. > >> setup_data, and the kernel could tune the platform UART settings accordingly. >> "Should be simple" (TM). > > Yep, that wouldn't require any invasive modification of the platform > drivers. > > Three flags should be sufficient: > - Use 0x2f8 > - Use 0x3f8 > - Use dbgcon Nope, 4: PC-UART0..3. dbgcon has nothing to do with this. If we want to propagate the comm region settings into some "console=X", that would be a pure kernel command line tuning by cell-linux. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/587c7a49-cf58-b9b3-3a80-454ac165636f%40siemens.com.
