Some of the platforms may have no legacy COM ports and only provide
an MMIO accessible UART. Add support for such to earlyprintk for the
boot phase of the kernel.

Andy Shevchenko (6):
  x86/boot: Convert early_serial_base to unsigned long
  x86/boot: Introduce helpers for serial I/O
  x86/boot: Split out parse_serial_port() helper for earlyprintk
  x86/boot: Allow longer parameter list for earlyprintk
  x86/boot: Also share MMIO accessors
  x86/boot: Introduce MMIO accessors and their support in earlyprintk

 arch/x86/boot/boot.h                          |   4 +-
 .../boot/compressed/early_serial_console.c    |   5 +-
 arch/x86/boot/compressed/misc.c               |   4 +-
 arch/x86/boot/compressed/misc.h               |   8 +-
 arch/x86/boot/early_serial_console.c          | 114 ++++++++++++++----
 arch/x86/boot/tty.c                           |   9 +-
 arch/x86/include/asm/io.h                     |  65 ----------
 arch/x86/include/asm/shared/io.h              |  68 +++++++++++
 8 files changed, 177 insertions(+), 100 deletions(-)

-- 
2.47.2

On Fri, 2025-05-02 at 15:29 +0300, Andy Shevchenko wrote:
> Some of the platforms may have no legacy COM ports and only provide
> an MMIO accessible UART. Add support for such to earlyprintk for the
> boot phase of the kernel.

Aha, I understand now... you've added this *only* for the boot code,
and haven't added the corresponding support to the in-kernel
earlyprintk, in arch/x86/kernel/early_printk.c

The latter does already support MMIO but it only supports a 32-bit
stride, not 8-bit.

Please could you make that consistent, and ensure the earlyprintk=
arguments function the same for both phases? I'm happy to add the
kexec-debug parts on top of *that*.

It would be really helpful if we could test this in QEMU; it shouldn't
be that hard to make it provide a 16550 on MMIO, along the lines of the
one-line hack I posted yesterday.

On Tue, May 06, 2025 at 12:38:21PM -0700, David Woodhouse wrote:
> On Fri, 2025-05-02 at 15:29 +0300, Andy Shevchenko wrote:
> > Some of the platforms may have no legacy COM ports and only provide
> > an MMIO accessible UART. Add support for such to earlyprintk for the
> > boot phase of the kernel.
> 
> Aha, I understand now... you've added this *only* for the boot code,
> and haven't added the corresponding support to the in-kernel
> earlyprintk, in arch/x86/kernel/early_printk.c

Haven't added yet. This is part 1 only.

> The latter does already support MMIO but it only supports a 32-bit
> stride, not 8-bit.
> 
> Please could you make that consistent, and ensure the earlyprintk=
> arguments function the same for both phases? I'm happy to add the
> kexec-debug parts on top of *that*.

It's not as easy as it looks like. I had done in the past the comparison table
of what we have between all early*=... for serial consoles and it all so
inconsistent to begin with. A big work needs to be fulfilled in order to put
this mess in order. Hence this is just the first step.

> It would be really helpful if we could test this in QEMU; it shouldn't
> be that hard to make it provide a 16550 on MMIO, along the lines of the
> one-line hack I posted yesterday.

I understand. But if no go for this series, I don't won't to spend time on
the next part.

In any case, thanks for looking into this.

-- 
With Best Regards,
Andy Shevchenko

On Fri, 2025-05-02 at 15:29 +0300, Andy Shevchenko wrote:
> Some of the platforms may have no legacy COM ports and only provide
> an MMIO accessible UART. Add support for such to earlyprintk for the
> boot phase of the kernel.

Shiny. I had to hack QEMU's PCI serial port to do unnatural things, in
order to test the mmio32 variant which was the only thing the
earlyprintk code used to support. But I *did* so, and it works with the
kexec debugging.

Can you add support for this mode to the kexec debugging too, please?

I believe it's currently in tip/asm. This should be a simple example to
work from:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/asm&id=7516e7216bdfb9e2fab0a0ca3bd23cb2e61e46ed

On Fri, May 02, 2025 at 10:33:49AM -0700, David Woodhouse wrote:
> On Fri, 2025-05-02 at 15:29 +0300, Andy Shevchenko wrote:
> > Some of the platforms may have no legacy COM ports and only provide
> > an MMIO accessible UART. Add support for such to earlyprintk for the
> > boot phase of the kernel.
> 
> Shiny. I had to hack QEMU's PCI serial port to do unnatural things, in
> order to test the mmio32 variant which was the only thing the
> earlyprintk code used to support. But I *did* so, and it works with the
> kexec debugging.
> 
> Can you add support for this mode to the kexec debugging too, please?

Do you mean to add MMIO 8-bit to kexec assembly code and other parts like you
did in the below mentioned change?

I can try it at some point, but have no time right now for this.
I would appreciate if you can give a try for this patch series
functionality to see if it helps for the initial messages (as
far as I understand you also want to have this in the second
kernel, right?).

> I believe it's currently in tip/asm. This should be a simple example to
> work from:
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/asm&id=7516e7216bdfb9e2fab0a0ca3bd23cb2e61e46ed



-- 
With Best Regards,
Andy Shevchenko

On Mon, 2025-05-05 at 17:05 +0300, Andy Shevchenko wrote:
> On Fri, May 02, 2025 at 10:33:49AM -0700, David Woodhouse wrote:
> > On Fri, 2025-05-02 at 15:29 +0300, Andy Shevchenko wrote:
> > > Some of the platforms may have no legacy COM ports and only provide
> > > an MMIO accessible UART. Add support for such to earlyprintk for the
> > > boot phase of the kernel.
> > 
> > Shiny. I had to hack QEMU's PCI serial port to do unnatural things, in
> > order to test the mmio32 variant which was the only thing the
> > earlyprintk code used to support. But I *did* so, and it works with the
> > kexec debugging.
> > 
> > Can you add support for this mode to the kexec debugging too, please?
> 
> Do you mean to add MMIO 8-bit to kexec assembly code and other parts like you
> did in the below mentioned change?
> 
> I can try it at some point, but have no time right now for this.
> I would appreciate if you can give a try for this patch series
> functionality to see if it helps for the initial messages (as
> far as I understand you also want to have this in the second
> kernel, right?).


I'll see if I can find the time to take a look. Got a branch I can pull
your series from?

On Mon, May 05, 2025 at 07:35:04AM -0700, David Woodhouse wrote:
> On Mon, 2025-05-05 at 17:05 +0300, Andy Shevchenko wrote:
> > On Fri, May 02, 2025 at 10:33:49AM -0700, David Woodhouse wrote:
> > > On Fri, 2025-05-02 at 15:29 +0300, Andy Shevchenko wrote:
> > > > Some of the platforms may have no legacy COM ports and only provide
> > > > an MMIO accessible UART. Add support for such to earlyprintk for the
> > > > boot phase of the kernel.
> > > 
> > > Shiny. I had to hack QEMU's PCI serial port to do unnatural things, in
> > > order to test the mmio32 variant which was the only thing the
> > > earlyprintk code used to support. But I *did* so, and it works with the
> > > kexec debugging.
> > > 
> > > Can you add support for this mode to the kexec debugging too, please?
> > 
> > Do you mean to add MMIO 8-bit to kexec assembly code and other parts like you
> > did in the below mentioned change?
> > 
> > I can try it at some point, but have no time right now for this.
> > I would appreciate if you can give a try for this patch series
> > functionality to see if it helps for the initial messages (as
> > far as I understand you also want to have this in the second
> > kernel, right?).
> 
> I'll see if I can find the time to take a look. Got a branch I can pull
> your series from?

Yeo, https://bitbucket.org/andy-shev/linux/commits/branch/topic%2Fx86%2Fboot-earlyprintk.


-- 
With Best Regards,
Andy Shevchenko

On Mon, May 05, 2025 at 05:59:48PM +0300, Andy Shevchenko wrote:
> On Mon, May 05, 2025 at 07:35:04AM -0700, David Woodhouse wrote:
> > On Mon, 2025-05-05 at 17:05 +0300, Andy Shevchenko wrote:
> > > On Fri, May 02, 2025 at 10:33:49AM -0700, David Woodhouse wrote:
> > > > On Fri, 2025-05-02 at 15:29 +0300, Andy Shevchenko wrote:
> > > > > Some of the platforms may have no legacy COM ports and only provide
> > > > > an MMIO accessible UART. Add support for such to earlyprintk for the
> > > > > boot phase of the kernel.
> > > > 
> > > > Shiny. I had to hack QEMU's PCI serial port to do unnatural things, in
> > > > order to test the mmio32 variant which was the only thing the
> > > > earlyprintk code used to support. But I *did* so, and it works with the
> > > > kexec debugging.
> > > > 
> > > > Can you add support for this mode to the kexec debugging too, please?
> > > 
> > > Do you mean to add MMIO 8-bit to kexec assembly code and other parts like you
> > > did in the below mentioned change?
> > > 
> > > I can try it at some point, but have no time right now for this.
> > > I would appreciate if you can give a try for this patch series
> > > functionality to see if it helps for the initial messages (as
> > > far as I understand you also want to have this in the second
> > > kernel, right?).
> > 
> > I'll see if I can find the time to take a look. Got a branch I can pull
> > your series from?
> 
> Yeo, https://bitbucket.org/andy-shev/linux/commits/branch/topic%2Fx86%2Fboot-earlyprintk.

But just FYI that with `b4` it's as easy to pull from the mailing list as from
a branch:

	b4 am 20250502123145.4066635-1-andriy.shevchenko@linux.intel.com
	git am -C1 -s ...

-- 
With Best Regards,
Andy Shevchenko

On Mon, 2025-05-05 at 18:01 +0300, Andy Shevchenko wrote:
> On Mon, May 05, 2025 at 05:59:48PM +0300, Andy Shevchenko wrote:
> > On Mon, May 05, 2025 at 07:35:04AM -0700, David Woodhouse wrote:
> > > On Mon, 2025-05-05 at 17:05 +0300, Andy Shevchenko wrote:
> > > > On Fri, May 02, 2025 at 10:33:49AM -0700, David Woodhouse
> > > > wrote:
> > > > > On Fri, 2025-05-02 at 15:29 +0300, Andy Shevchenko wrote:
> > > > > > Some of the platforms may have no legacy COM ports and only
> > > > > > provide
> > > > > > an MMIO accessible UART. Add support for such to
> > > > > > earlyprintk for the
> > > > > > boot phase of the kernel.
> > > > > 
> > > > > Shiny. I had to hack QEMU's PCI serial port to do unnatural
> > > > > things, in
> > > > > order to test the mmio32 variant which was the only thing the
> > > > > earlyprintk code used to support. But I *did* so, and it
> > > > > works with the
> > > > > kexec debugging.
> > > > > 
> > > > > Can you add support for this mode to the kexec debugging too,
> > > > > please?
> > > > 
> > > > Do you mean to add MMIO 8-bit to kexec assembly code and other
> > > > parts like you
> > > > did in the below mentioned change?
> > > > 
> > > > I can try it at some point, but have no time right now for
> > > > this.
> > > > I would appreciate if you can give a try for this patch series
> > > > functionality to see if it helps for the initial messages (as
> > > > far as I understand you also want to have this in the second
> > > > kernel, right?).
> > > 
> > > I'll see if I can find the time to take a look. Got a branch I
> > > can pull
> > > your series from?
> > 
> > Yeo,
> > https://bitbucket.org/andy-shev/linux/commits/branch/topic%2Fx86%2Fboot-earlyprintk
> > .
> 
> But just FYI that with `b4` it's as easy to pull from the mailing
> list as from
> a branch:
> 
> 	b4 am
> 20250502123145.4066635-1-andriy.shevchenko@linux.intel.com
> 	git am -C1 -s ...


Thanks. Should I be expecting this to work...?

qemu-system-x86_64 -display none -vga none  -accel kvm,kernel-irqchip=split \
  -kernel arch/x86/boot/bzImage \
  -append "console=ttyS4 root=/dev/vda1 earlyprintk=pciserial" \
  -chardev stdio,mux=on,id=char0,signal=off -mon char0 -device pci-serial,chardev=char0


I get no early output (I think it's still using the mmio32 variant),
and I only see output from when the real driver takes over:

[    0.894054] printk: legacy console [ttyS4] enabled
[    0.895498] printk: legacy bootconsole [earlyser0] disabled
...

On Mon, 2025-05-05 at 16:32 -0700, David Woodhouse wrote:
> 
> Thanks. Should I be expecting this to work...?
> 
> qemu-system-x86_64 -display none -vga none  -accel kvm,kernel-irqchip=split \
>   -kernel arch/x86/boot/bzImage \
>   -append "console=ttyS4 root=/dev/vda1 earlyprintk=pciserial" \
>   -chardev stdio,mux=on,id=char0,signal=off -mon char0 -device pci-serial,chardev=char0

Hm, no, qemu's pci-serial is PIO. I'd need to do this:

--- a/hw/char/serial-pci.c
+++ b/hw/char/serial-pci.c
@@ -58,7 +58,7 @@ static void serial_pci_realize(PCIDevice *dev, Error **errp)
     s->irq = pci_allocate_irq(&pci->dev);
 
     memory_region_init_io(&s->io, OBJECT(pci), &serial_io_ops, s, "serial", 8);
-    pci_register_bar(&pci->dev, 0, PCI_BASE_ADDRESS_SPACE_IO, &s->io);
+    pci_register_bar(&pci->dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, &s->io);
 }
 
 static void serial_pci_exit(PCIDevice *dev)


And then the kernel's 'earlyprintk=pciserial' needs to be told the BDF,
e.g. earlyprintk=pciserial,00:03.0,keep

And it's still defaulting to mmio32 unless I do this in the kernel...

--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -198,7 +198,7 @@ static __init void early_serial_init(char *s)
 
 static __noendbr void mem32_serial_out(unsigned long addr, int offset, int value)
 {
-       u32 __iomem *vaddr = (u32 __iomem *)addr;
+       u8 __iomem *vaddr = (u8 __iomem *)addr;
        /* shift implied by pointer type */
        writel(value, vaddr + offset);
 }
@@ -206,7 +206,7 @@ ANNOTATE_NOENDBR_SYM(mem32_serial_out);
 
 static __noendbr unsigned int mem32_serial_in(unsigned long addr, int offset)
 {
-       u32 __iomem *vaddr = (u32 __iomem *)addr;
+       u8 __iomem *vaddr = (u8 __iomem *)addr;
        /* shift implied by pointer type */
        return readl(vaddr + offset);
 }


If you can get this part working sanely, I'll happily add the kexec debug part.