> The question to me is, if Grub uses the IRQ. If it does, it may as > well hang on that. > Nope, Grub doesn't seem to use the IRQ.
https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/term/ns8250. c#n95 /* Turn off the interrupt. */ grub_outb (0, port->port + UART_IER); So that potential pitfall does not apply. As for the I/O ports, I don't really see a principal problem. In general, for various physical address spaces, Linux running in protected mode, requires an "address window remap" operation during driver startup / device instance initialization - applies to code running in the kernel context (I'm not referring to the user space here, that's a whole different story yet). That said, the x86 architecture distinguishes between memory-mapped IO and port IO. The MMIO does technically require a "remap" operation, to have the MMIO window fit within all that "memory protection" clockwork. But for Port IO, on x86, the "mapping" is in fact 1:1, a no-op. The IO ports that you can see in Linux can be pretty much relied on to be the same *before* the kernel even gets loaded. On the PCI bus, the port IO ranges are assigned during PCI bus enumeration done by the BIOS. Perhaps Linux can re-enumerate the bus and assign the windows differently, but in my everyday reality, this does not happen - i.e. the PCI IO windows are the same since right after the BIOS POST. I.e., the only condition for the PCI-based IO window to work is, that the PCI bus has been set up by the BIOS (bridges configured, including the IO address windows decoded). Which is likely to have happened just fine. Frank