Re: Serial Console Debugging Issue

[Frantisek Rysanek]

> 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