[PATCH v1 0/1] [RISC-V] replace SBI early console with 8250 UART

[PATCH v1 0/1] [RISC-V] replace SBI early console with 8250 UART

[Zhang Zheng]

The legacy SBI console extension is planned for deprecation. Replace the
RISC-V early printk backend with direct access to 8250 UART MMIO.

This also addresses truncated output observed on SpacemiT K3 when
switching from early printk to dtuart. Direct UART access lets early
printk flush the UART after each string before the dtuart driver takes
over and clear it's FIFO, which cause the truncated uart output.

The truncated uart looks like:

  (XEN) Command line: dtuart=/soc/uart@d4017000:115200/921600 console=dtuart sync_console
  (XEN) Domain heap initialised
  (XEN) Booting using Device Tree
  (XEN) /home/zz/dev/git/xen_stuff/xen/xen/arch/riscv/cpufeature.c:710: SSTC detected; supported for Xen use, but not for guests
  (XEN) Looking for dtuart at "/soc/uart@d40 __  __            _  _    ____  _____                    _        _     _
   \ \/ /___ _ __   | || |  |___ \|___ /    _   _ _ __  ___| |_ __ _| |__ | | ___
    \  // _ \ '_ \  | || |_   __) | |_ \ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
    /  \  __/ | | | |__   _| / __/ ___) |__| |_| | | | \__ \ || (_| | |_) | |  __/
   /_/\_\___|_| |_|    |_|(_)_____|____/    \__,_|_| |_|___/\__\__,_|_.__/|_|\___|

  (XEN) Xen version 4.23-unstable (zz@) (riscv64-linux-gnu-gcc (GCC) 15.1.0) debug=y ubsan=y Sat Sep 26 14:50:31 CST 2026
  (XEN) Latest ChangeSet: Fri Sep 18 10:11:27 2026 +0800 git:77544a69ea

Zheng Zhang (1):
  xen/riscv: replace SBI early console with 8250 UAR

 xen/arch/riscv/Kconfig.debug              | 53 ++++++++++++++++++++--
 xen/arch/riscv/configs/tiny64_defconfig   |  2 +
 xen/arch/riscv/early_printk.c             | 37 +++++++---------
 xen/arch/riscv/include/asm/early_printk.h | 12 +++++
 xen/arch/riscv/include/asm/fixmap.h       |  6 ++-
 xen/arch/riscv/include/asm/sbi.h          |  7 ---
 xen/arch/riscv/mm.c                       | 41 +++++++++++++----
 xen/arch/riscv/riscv64/Makefile           |  1 +
 xen/arch/riscv/riscv64/debug-8250.inc     | 51 +++++++++++++++++++++
 xen/arch/riscv/riscv64/debug.S            | 54 +++++++++++++++++++++++
 xen/arch/riscv/sbi.c                      |  5 ---
 11 files changed, 223 insertions(+), 46 deletions(-)
 create mode 100644 xen/arch/riscv/riscv64/debug-8250.inc
 create mode 100644 xen/arch/riscv/riscv64/debug.S

base-commit: 4c1aba82cff95ab11f7fe4af8965a06703537288
-- 
2.54.0

[PATCH v1 1/1] xen/riscv: replace SBI early console with 8250 UART

[Zhang Zheng]

As noted by the TODO, the legacy SBI console extension is planned
for deprecation. Replace it with direct access to UART MMIO.

Signed-off-by: Zhang Zheng <zhangzheng@iscas.ac.cn>
---
 xen/arch/riscv/Kconfig.debug              | 53 ++++++++++++++++++++--
 xen/arch/riscv/configs/tiny64_defconfig   |  2 +
 xen/arch/riscv/early_printk.c             | 37 +++++++---------
 xen/arch/riscv/include/asm/early_printk.h | 12 +++++
 xen/arch/riscv/include/asm/fixmap.h       |  6 ++-
 xen/arch/riscv/include/asm/sbi.h          |  7 ---
 xen/arch/riscv/mm.c                       | 41 +++++++++++++----
 xen/arch/riscv/riscv64/Makefile           |  1 +
 xen/arch/riscv/riscv64/debug-8250.inc     | 51 +++++++++++++++++++++
 xen/arch/riscv/riscv64/debug.S            | 54 +++++++++++++++++++++++
 xen/arch/riscv/sbi.c                      |  5 ---
 11 files changed, 223 insertions(+), 46 deletions(-)
 create mode 100644 xen/arch/riscv/riscv64/debug-8250.inc
 create mode 100644 xen/arch/riscv/riscv64/debug.S

diff --git a/xen/arch/riscv/Kconfig.debug b/xen/arch/riscv/Kconfig.debug
index 608c9ff832..51536e7151 100644
--- a/xen/arch/riscv/Kconfig.debug
+++ b/xen/arch/riscv/Kconfig.debug
@@ -1,5 +1,50 @@
+choice
+	bool "Early printk"
+	optional
+	help
+	  You may want to enable early printk if you are debugging code
+	  that executes before the console is initialized.
+
+	  Note that selecting this option will limit Xen to a single UART
+	  definition. Attempting to boot the Xen image on a different
+	  platform will not work, so this option should not be enabled
+	  for Xen images that are intended to be portable.
+
+	  Choose one of the UART drivers for early printk, then specify
+	  parameters such as the base address.
+
+	config EARLY_UART_CHOICE_8250
+		select EARLY_UART_8250
+		bool "Early printk via 8250 UART"
+		help
+		  Say Y here if you wish early printk to direct its output
+		  to an already configured 8250-compatible UART.
+
+endchoice
+
+config EARLY_UART_8250
+	select EARLY_PRINTK
+	bool
+
 config EARLY_PRINTK
-    bool "Enable early printk"
-    default DEBUG
-    help
-      Enables early printk debug messages
+	bool
+
+config EARLY_UART_BASE_ADDRESS
+	depends on EARLY_UART_8250
+	hex "Early printk, physical base address of debug UART"
+
+config EARLY_UART_8250_REG_SHIFT
+	depends on EARLY_UART_8250
+	int "Early printk, left-shift to apply to the register offsets within the 8250 UART"
+	default 0
+	range 0 4
+	help
+	  EARLY_UART_8250_REG_SHIFT is, optionally, the left-shift to
+	  apply to the register offsets within the UART with early
+	  printk.
+
+	  Default to 0.
+
+config EARLY_PRINTK_INC
+	string
+	default "debug-8250.inc" if EARLY_UART_8250
diff --git a/xen/arch/riscv/configs/tiny64_defconfig b/xen/arch/riscv/configs/tiny64_defconfig
index 2399f7b918..438db66551 100644
--- a/xen/arch/riscv/configs/tiny64_defconfig
+++ b/xen/arch/riscv/configs/tiny64_defconfig
@@ -10,3 +10,5 @@ CONFIG_DEBUG=y
 CONFIG_DEBUG_INFO=y
 CONFIG_EXPERT=y
 CONFIG_QEMU_PLATFORM=y
+CONFIG_EARLY_UART_CHOICE_8250=y
+CONFIG_EARLY_UART_BASE_ADDRESS=0x10000000
diff --git a/xen/arch/riscv/early_printk.c b/xen/arch/riscv/early_printk.c
index 634141354c..bb2dc6c719 100644
--- a/xen/arch/riscv/early_printk.c
+++ b/xen/arch/riscv/early_printk.c
@@ -1,42 +1,37 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 /*
- * RISC-V early printk using SBI
+ * RISC-V early printk
  *
  * Copyright (C) 2021 Bobby Eshleman <bobbyeshleman@gmail.com>
  */
-#include <asm/early_printk.h>
-#include <asm/sbi.h>
+#include <xen/early_printk.h>
 
-/*
- * When the MMU is off during early boot, any C function called has to
- * use PC-relative rather than absolute address because the physical address
- * may not match the virtual address.
- *
- * To guarantee PC-relative address cmodel=medany should be used
- */
 #ifndef __riscv_cmodel_medany
 #error "early_*() can be called from head.S with MMU-off"
 #endif
 
-/*
- * TODO:
- *   sbi_console_putchar is already planned for deprecation
- *   so it should be reworked to use UART directly.
-*/
+void early_putch(char c);
+void early_flush(void);
+
 void early_puts(const char *s, size_t nr)
 {
     while ( nr-- > 0 )
     {
-        sbi_console_putchar(*s);
+        if ( *s == '\n' )
+            early_putch('\r');
+        early_putch(*s);
         s++;
     }
+
+    early_flush();
 }
 
 void early_printk(const char *str)
 {
-    while ( *str )
-    {
-        early_puts(str, 1);
-        str++;
-    }
+    const char *end = str;
+
+    while ( *end )
+        end++;
+
+    early_puts(str, end - str);
 }
diff --git a/xen/arch/riscv/include/asm/early_printk.h b/xen/arch/riscv/include/asm/early_printk.h
index 2750045bdd..e4c95ed7b4 100644
--- a/xen/arch/riscv/include/asm/early_printk.h
+++ b/xen/arch/riscv/include/asm/early_printk.h
@@ -3,6 +3,7 @@
 #ifndef ASM__RISCV__EARLY_PRINTK_H
 #define ASM__RISCV__EARLY_PRINTK_H
 
+#ifndef __ASSEMBLER__
 #include <xen/early_printk.h>
 
 #ifdef CONFIG_EARLY_PRINTK
@@ -10,5 +11,16 @@ void early_printk(const char *str);
 #else
 static inline void early_printk(const char *s) {};
 #endif
+#endif
+
+#ifdef CONFIG_EARLY_PRINTK
+
+#include <xen/page-size.h>
+#include <asm/fixmap.h>
+
+/* need to add the uart address offset in page to the fixmap address */
+#define EARLY_UART_VIRTUAL_ADDRESS \
+    (FIXMAP_ADDR(FIX_CONSOLE) + (CONFIG_EARLY_UART_BASE_ADDRESS & ~PAGE_MASK))
+#endif
 
 #endif /* ASM__RISCV__EARLY_PRINTK_H */
diff --git a/xen/arch/riscv/include/asm/fixmap.h b/xen/arch/riscv/include/asm/fixmap.h
index 085d135c15..66a78bb19d 100644
--- a/xen/arch/riscv/include/asm/fixmap.h
+++ b/xen/arch/riscv/include/asm/fixmap.h
@@ -17,8 +17,12 @@
 #define FIX_PMAP_BEGIN (0) /* Start of PMAP */
 #define FIX_PMAP_END (FIX_PMAP_BEGIN + NUM_FIX_PMAP - 1) /* End of PMAP */
 #define FIX_MISC (FIX_PMAP_END + 1)  /* Ephemeral mappings of hardware */
-
+#ifdef CONFIG_EARLY_PRINTK
+#define FIX_CONSOLE (FIX_MISC + 1) /* Early UART mapping */
+#define FIX_LAST FIX_CONSOLE
+#else
 #define FIX_LAST FIX_MISC
+#endif
 
 #define FIXADDR_START FIXMAP_ADDR(0)
 #define FIXADDR_TOP FIXMAP_ADDR(FIX_LAST + 1)
diff --git a/xen/arch/riscv/include/asm/sbi.h b/xen/arch/riscv/include/asm/sbi.h
index 1952868e96..d043fc7632 100644
--- a/xen/arch/riscv/include/asm/sbi.h
+++ b/xen/arch/riscv/include/asm/sbi.h
@@ -75,13 +75,6 @@ struct sbiret sbi_ecall(unsigned long ext, unsigned long fid,
                         unsigned long arg2, unsigned long arg3,
                         unsigned long arg4, unsigned long arg5);
 
-/**
- * Writes given character to the console device.
- *
- * @param ch The data to be written to the console.
- */
-void sbi_console_putchar(int ch);
-
 void sbi_shutdown(void);
 
 /*
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 610d111945..8480e61de2 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -76,6 +76,27 @@ stage1_pgtbl_nonroot[PGTBL_INITIAL_COUNT * PAGETABLE_ENTRIES];
 pte_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
 xen_fixmap[PAGETABLE_ENTRIES];
 
+#ifdef CONFIG_EARLY_PRINTK
+static void __init setup_early_uart_mapping(void)
+{
+    pte_t *pgtbl = stage1_pgtbl_root;
+    unsigned int i;
+
+    /* Add UART to the fixmap table. */
+    xen_fixmap[pt_index(0, EARLY_UART_VIRTUAL_ADDRESS)] =
+        paddr_to_pte(CONFIG_EARLY_UART_BASE_ADDRESS & PAGE_MASK,
+                     PAGE_HYPERVISOR_RW);
+
+    for ( i = HYP_PT_ROOT_LEVEL; i > 1; i-- )
+        pgtbl = (pte_t *)pte_to_paddr(
+            pgtbl[pt_index(i, FIXMAP_ADDR(0))]);
+
+    /* Map fixmap into the initial page tables. */
+    pgtbl[pt_index(1, FIXMAP_ADDR(0))] =
+        paddr_to_pte((paddr_t)xen_fixmap, PTE_TABLE);
+}
+#endif
+
 #define HANDLE_PGTBL(curr_lvl_num)                                          \
     index = pt_index(curr_lvl_num, page_addr);                              \
     if ( pte_is_valid(pgtbl[index]) )                                       \
@@ -243,18 +264,18 @@ void __init setup_fixmap_mappings(void)
         pte = &pte[pt_index(i, FIXMAP_ADDR(0))];
     }
 
-    BUG_ON(pte_is_valid(*pte));
-
-    tmp = paddr_to_pte(virt_to_maddr(&xen_fixmap), PTE_TABLE);
-    write_pte(pte, tmp);
+    if ( pte_is_valid(*pte) )
+        BUG_ON(pte_to_paddr(*pte) != virt_to_maddr(xen_fixmap));
+    else
+    {
+        tmp = paddr_to_pte(virt_to_maddr(xen_fixmap), PTE_TABLE);
+        write_pte(pte, tmp);
+    }
 
     RISCV_FENCE(rw, rw);
     sfence_vma();
 
-    /*
-     * We only need the zeroeth table allocated, but not the PTEs set, because
-     * set_fixmap() will set them on the fly.
-     */
+    /* Remaining fixmap entries are populated on demand by set_fixmap(). */
 }
 
 /*
@@ -314,6 +335,10 @@ void __init setup_initial_pagetables(void)
                           linker_end,
                           load_start);
 
+#ifdef CONFIG_EARLY_PRINTK
+    setup_early_uart_mapping();
+#endif
+
     if ( linker_start == load_start )
         return;
 
diff --git a/xen/arch/riscv/riscv64/Makefile b/xen/arch/riscv/riscv64/Makefile
index 3340058c08..a35968ead7 100644
--- a/xen/arch/riscv/riscv64/Makefile
+++ b/xen/arch/riscv/riscv64/Makefile
@@ -1 +1,2 @@
+obj-$(CONFIG_EARLY_PRINTK) += debug.o
 obj-y += head.o
diff --git a/xen/arch/riscv/riscv64/debug-8250.inc b/xen/arch/riscv/riscv64/debug-8250.inc
new file mode 100644
index 0000000000..5918e74cbd
--- /dev/null
+++ b/xen/arch/riscv/riscv64/debug-8250.inc
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0-only
+ *
+ * xen/arch/riscv/riscv64/debug-8250.inc
+ *
+ * 8250 specific debug code
+ *
+ * Copyright (c) 2013 Applied Micro.
+ * Copyright (c) 2026 Zheng Zhang.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <xen/8250-uart.h>
+
+/*
+ * UART wait UART to be ready to transmit
+ * xb: register which contains the UART base address
+ * c: scratch register
+ */
+.macro early_uart_ready xb c
+1:
+        lbu     \c, (UART_LSR << CONFIG_EARLY_UART_8250_REG_SHIFT)(\xb)
+        andi    \c, \c, UART_LSR_THRE
+        xori    \c, \c, UART_LSR_THRE
+        bnez    \c, 1b
+.endm
+
+/*
+ * UART transmit character
+ * xb: register which contains the UART base address
+ * wt: register which contains the character to transmit
+ */
+.macro early_uart_transmit xb wt
+        /* UART_THR transmit holding */
+        sb      \wt, (UART_THR << CONFIG_EARLY_UART_8250_REG_SHIFT)(\xb)
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/riscv/riscv64/debug.S b/xen/arch/riscv/riscv64/debug.S
new file mode 100644
index 0000000000..4e7465e1d8
--- /dev/null
+++ b/xen/arch/riscv/riscv64/debug.S
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: GPL-2.0-only
+ *
+ * xen/arch/riscv/riscv64/debug.S
+ *
+ * Wrapper for early printk
+ *
+ * Julien Grall <julien.grall@linaro.org>
+ * Copyright (c) 2013 Linaro Limited.
+ * Copyright (c) 2026 Zheng Zhang.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/asm.h>
+#include <asm/early_printk.h>
+#include <asm/riscv_encoding.h>
+
+#include CONFIG_EARLY_PRINTK_INC
+
+.macro early_uart_base bs, c
+        li      \bs, CONFIG_EARLY_UART_BASE_ADDRESS
+        csrr    \c, CSR_SATP
+        beqz    \c, 1f
+        li      \bs, EARLY_UART_VIRTUAL_ADDRESS
+1:
+.endm
+
+/* Print the character in a0. */
+FUNC(early_putch)
+        early_uart_base t0, t1
+        early_uart_ready t0, t1
+        andi    a0, a0, 0xff
+        early_uart_transmit t0, a0
+        ret
+END(early_putch)
+
+/* Wait until both the transmit FIFO and shift register are empty. */
+FUNC(early_flush)
+        early_uart_base t0, t1
+1:
+        lbu     t1, (UART_LSR << CONFIG_EARLY_UART_8250_REG_SHIFT)(t0)
+        andi    t1, t1, (UART_LSR_THRE | UART_LSR_TEMT)
+        xori    t1, t1, (UART_LSR_THRE | UART_LSR_TEMT)
+        bnez    t1, 1b
+        ret
+END(early_flush)
diff --git a/xen/arch/riscv/sbi.c b/xen/arch/riscv/sbi.c
index 3576e26033..bca3ebdca5 100644
--- a/xen/arch/riscv/sbi.c
+++ b/xen/arch/riscv/sbi.c
@@ -72,11 +72,6 @@ static int sbi_err_map_xen_errno(int err)
     };
 }
 
-void sbi_console_putchar(int ch)
-{
-    sbi_ecall(SBI_EXT_0_1_CONSOLE_PUTCHAR, 0, ch, 0, 0, 0, 0, 0);
-}
-
 void sbi_shutdown(void)
 {
     sbi_ecall(SBI_EXT_0_1_SHUTDOWN, 0, 0, 0, 0, 0, 0, 0);
-- 
2.54.0

Re: [PATCH v1 0/1] [RISC-V] replace SBI early console with 8250 UART

[Oleksii Kurochko]

On 9/28/26 4:38 AM, Zhang Zheng wrote:
> The legacy SBI console extension is planned for deprecation. Replace the
> RISC-V early printk backend with direct access to 8250 UART MMIO.

Won't it better just to start to add support of newer SBI? It provides 
pretty good support + faster as it supports passing of string instead of 
one char.

Also, I think it will lead to lesser changes.

~ Oleksii

> 
> This also addresses truncated output observed on SpacemiT K3 when
> switching from early printk to dtuart. Direct UART access lets early
> printk flush the UART after each string before the dtuart driver takes
> over and clear it's FIFO, which cause the truncated uart output.>
> The truncated uart looks like:
> 
>    (XEN) Command line: dtuart=/soc/uart@d4017000:115200/921600 console=dtuart sync_console
>    (XEN) Domain heap initialised
>    (XEN) Booting using Device Tree
>    (XEN) /home/zz/dev/git/xen_stuff/xen/xen/arch/riscv/cpufeature.c:710: SSTC detected; supported for Xen use, but not for guests
>    (XEN) Looking for dtuart at "/soc/uart@d40 __  __            _  _    ____  _____                    _        _     _
>     \ \/ /___ _ __   | || |  |___ \|___ /    _   _ _ __  ___| |_ __ _| |__ | | ___
>      \  // _ \ '_ \  | || |_   __) | |_ \ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
>      /  \  __/ | | | |__   _| / __/ ___) |__| |_| | | | \__ \ || (_| | |_) | |  __/
>     /_/\_\___|_| |_|    |_|(_)_____|____/    \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
> 
>    (XEN) Xen version 4.23-unstable (zz@) (riscv64-linux-gnu-gcc (GCC) 15.1.0) debug=y ubsan=y Sat Sep 26 14:50:31 CST 2026
>    (XEN) Latest ChangeSet: Fri Sep 18 10:11:27 2026 +0800 git:77544a69ea
> 
> Zheng Zhang (1):
>    xen/riscv: replace SBI early console with 8250 UAR
> 
>   xen/arch/riscv/Kconfig.debug              | 53 ++++++++++++++++++++--
>   xen/arch/riscv/configs/tiny64_defconfig   |  2 +
>   xen/arch/riscv/early_printk.c             | 37 +++++++---------
>   xen/arch/riscv/include/asm/early_printk.h | 12 +++++
>   xen/arch/riscv/include/asm/fixmap.h       |  6 ++-
>   xen/arch/riscv/include/asm/sbi.h          |  7 ---
>   xen/arch/riscv/mm.c                       | 41 +++++++++++++----
>   xen/arch/riscv/riscv64/Makefile           |  1 +
>   xen/arch/riscv/riscv64/debug-8250.inc     | 51 +++++++++++++++++++++
>   xen/arch/riscv/riscv64/debug.S            | 54 +++++++++++++++++++++++
>   xen/arch/riscv/sbi.c                      |  5 ---
>   11 files changed, 223 insertions(+), 46 deletions(-)
>   create mode 100644 xen/arch/riscv/riscv64/debug-8250.inc
>   create mode 100644 xen/arch/riscv/riscv64/debug.S
> 
> base-commit: 4c1aba82cff95ab11f7fe4af8965a06703537288

Re: [PATCH v1 0/1] [RISC-V] replace SBI early console with 8250 UART

[Zhang Zheng]

On Mon, Sep 28, 2026 at 09:38:14AM +0200, Oleksii Kurochko wrote:
> 
> 
> On 9/28/26 4:38 AM, Zhang Zheng wrote:
> > The legacy SBI console extension is planned for deprecation. Replace the
> > RISC-V early printk backend with direct access to 8250 UART MMIO.
> 
> Won't it better just to start to add support of newer SBI? It provides
> pretty good support + faster as it supports passing of string instead of one
> char.
> 

Using the newer SBI DBCN extension would indeed result in a smaller change. At
the time, I mainly followed the direction suggested by the TODO and referred
directly to the arm64 implementation, from which most of the code was adapted.

> Also, I think it will lead to lesser changes.
> 

If falling back to SBI console putchar is acceptable, DBCN should work
well here.

> ~ Oleksii
> 
> > 
> > This also addresses truncated output observed on SpacemiT K3 when
> > switching from early printk to dtuart. Direct UART access lets early
> > printk flush the UART after each string before the dtuart driver takes
> > over and clear it's FIFO, which cause the truncated uart output.>
> > The truncated uart looks like:
> > 
> >    (XEN) Command line: dtuart=/soc/uart@d4017000:115200/921600 console=dtuart sync_console
> >    (XEN) Domain heap initialised
> >    (XEN) Booting using Device Tree
> >    (XEN) /home/zz/dev/git/xen_stuff/xen/xen/arch/riscv/cpufeature.c:710: SSTC detected; supported for Xen use, but not for guests
> >    (XEN) Looking for dtuart at "/soc/uart@d40 __  __            _  _    ____  _____                    _        _     _
> >     \ \/ /___ _ __   | || |  |___ \|___ /    _   _ _ __  ___| |_ __ _| |__ | | ___
> >      \  // _ \ '_ \  | || |_   __) | |_ \ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
> >      /  \  __/ | | | |__   _| / __/ ___) |__| |_| | | | \__ \ || (_| | |_) | |  __/
> >     /_/\_\___|_| |_|    |_|(_)_____|____/    \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
> > 
> >    (XEN) Xen version 4.23-unstable (zz@) (riscv64-linux-gnu-gcc (GCC) 15.1.0) debug=y ubsan=y Sat Sep 26 14:50:31 CST 2026
> >    (XEN) Latest ChangeSet: Fri Sep 18 10:11:27 2026 +0800 git:77544a69ea
> > 
> > Zheng Zhang (1):
> >    xen/riscv: replace SBI early console with 8250 UAR
> > 
> >   xen/arch/riscv/Kconfig.debug              | 53 ++++++++++++++++++++--
> >   xen/arch/riscv/configs/tiny64_defconfig   |  2 +
> >   xen/arch/riscv/early_printk.c             | 37 +++++++---------
> >   xen/arch/riscv/include/asm/early_printk.h | 12 +++++
> >   xen/arch/riscv/include/asm/fixmap.h       |  6 ++-
> >   xen/arch/riscv/include/asm/sbi.h          |  7 ---
> >   xen/arch/riscv/mm.c                       | 41 +++++++++++++----
> >   xen/arch/riscv/riscv64/Makefile           |  1 +
> >   xen/arch/riscv/riscv64/debug-8250.inc     | 51 +++++++++++++++++++++
> >   xen/arch/riscv/riscv64/debug.S            | 54 +++++++++++++++++++++++
> >   xen/arch/riscv/sbi.c                      |  5 ---
> >   11 files changed, 223 insertions(+), 46 deletions(-)
> >   create mode 100644 xen/arch/riscv/riscv64/debug-8250.inc
> >   create mode 100644 xen/arch/riscv/riscv64/debug.S
> > 
> > base-commit: 4c1aba82cff95ab11f7fe4af8965a06703537288

Re: [PATCH v1 0/1] [RISC-V] replace SBI early console with 8250 UART

[Oleksii Kurochko]

On 9/28/26 10:40 AM, Zhang Zheng wrote:
> On Mon, Sep 28, 2026 at 09:38:14AM +0200, Oleksii Kurochko wrote:
>>
>>
>> On 9/28/26 4:38 AM, Zhang Zheng wrote:
>>> The legacy SBI console extension is planned for deprecation. Replace the
>>> RISC-V early printk backend with direct access to 8250 UART MMIO.
>>
>> Won't it better just to start to add support of newer SBI? It provides
>> pretty good support + faster as it supports passing of string instead of one
>> char.
>>
> 
> Using the newer SBI DBCN extension would indeed result in a smaller change. At
> the time, I mainly followed the direction suggested by the TODO and referred
> directly to the arm64 implementation, from which most of the code was adapted.

I think TODO was written at that way because I missed DBCN (or it wasn't 
ratified at that moment). Considering that it is ratified now ...

> 
>> Also, I think it will lead to lesser changes.
>>
> 
> If falling back to SBI console putchar is acceptable, DBCN should work
> well here.

... I prefer to use SBI functionality (in the current case DBCN) as 
maximum as possible so if there is no any reason (and I don't see at the 
moment it) which doesn't allow us to use DBCN here, I would prefer to 
use DBCN.

If you still want to in the way suggested by TODO then some parts which 
are common between Arm and RISC-V should be moved to common instead of 
introducing them in RISC-V specific folder.

Let me know which approach you are going to follow. If the current one 
you already introduced then I will start to review it, if you will go 
SBI-way then I prefer to wait for your v2.

~ Oleksii

>>>
>>> This also addresses truncated output observed on SpacemiT K3 when
>>> switching from early printk to dtuart. Direct UART access lets early
>>> printk flush the UART after each string before the dtuart driver takes
>>> over and clear it's FIFO, which cause the truncated uart output.>
>>> The truncated uart looks like:
>>>
>>>     (XEN) Command line: dtuart=/soc/uart@d4017000:115200/921600 console=dtuart sync_console
>>>     (XEN) Domain heap initialised
>>>     (XEN) Booting using Device Tree
>>>     (XEN) /home/zz/dev/git/xen_stuff/xen/xen/arch/riscv/cpufeature.c:710: SSTC detected; supported for Xen use, but not for guests
>>>     (XEN) Looking for dtuart at "/soc/uart@d40 __  __            _  _    ____  _____                    _        _     _
>>>      \ \/ /___ _ __   | || |  |___ \|___ /    _   _ _ __  ___| |_ __ _| |__ | | ___
>>>       \  // _ \ '_ \  | || |_   __) | |_ \ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
>>>       /  \  __/ | | | |__   _| / __/ ___) |__| |_| | | | \__ \ || (_| | |_) | |  __/
>>>      /_/\_\___|_| |_|    |_|(_)_____|____/    \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
>>>
>>>     (XEN) Xen version 4.23-unstable (zz@) (riscv64-linux-gnu-gcc (GCC) 15.1.0) debug=y ubsan=y Sat Sep 26 14:50:31 CST 2026
>>>     (XEN) Latest ChangeSet: Fri Sep 18 10:11:27 2026 +0800 git:77544a69ea
>>>
>>> Zheng Zhang (1):
>>>     xen/riscv: replace SBI early console with 8250 UAR
>>>
>>>    xen/arch/riscv/Kconfig.debug              | 53 ++++++++++++++++++++--
>>>    xen/arch/riscv/configs/tiny64_defconfig   |  2 +
>>>    xen/arch/riscv/early_printk.c             | 37 +++++++---------
>>>    xen/arch/riscv/include/asm/early_printk.h | 12 +++++
>>>    xen/arch/riscv/include/asm/fixmap.h       |  6 ++-
>>>    xen/arch/riscv/include/asm/sbi.h          |  7 ---
>>>    xen/arch/riscv/mm.c                       | 41 +++++++++++++----
>>>    xen/arch/riscv/riscv64/Makefile           |  1 +
>>>    xen/arch/riscv/riscv64/debug-8250.inc     | 51 +++++++++++++++++++++
>>>    xen/arch/riscv/riscv64/debug.S            | 54 +++++++++++++++++++++++
>>>    xen/arch/riscv/sbi.c                      |  5 ---
>>>    11 files changed, 223 insertions(+), 46 deletions(-)
>>>    create mode 100644 xen/arch/riscv/riscv64/debug-8250.inc
>>>    create mode 100644 xen/arch/riscv/riscv64/debug.S
>>>
>>> base-commit: 4c1aba82cff95ab11f7fe4af8965a06703537288
> 

Re: [PATCH v1 0/1] [RISC-V] replace SBI early console with 8250 UART

[Zhang Zheng]

On Mon, Sep 28, 2026 at 11:31:06AM +0200, Oleksii Kurochko wrote:
> 
> 
> On 9/28/26 10:40 AM, Zhang Zheng wrote:
> > On Mon, Sep 28, 2026 at 09:38:14AM +0200, Oleksii Kurochko wrote:
> > > 
> > > 
> > > On 9/28/26 4:38 AM, Zhang Zheng wrote:
> > > > The legacy SBI console extension is planned for deprecation. Replace the
> > > > RISC-V early printk backend with direct access to 8250 UART MMIO.
> > > 
> > > Won't it better just to start to add support of newer SBI? It provides
> > > pretty good support + faster as it supports passing of string instead of one
> > > char.
> > > 
> > 
> > Using the newer SBI DBCN extension would indeed result in a smaller change. At
> > the time, I mainly followed the direction suggested by the TODO and referred
> > directly to the arm64 implementation, from which most of the code was adapted.
> 
> I think TODO was written at that way because I missed DBCN (or it wasn't
> ratified at that moment). Considering that it is ratified now ...
> 
> > 
> > > Also, I think it will lead to lesser changes.
> > > 
> > 
> > If falling back to SBI console putchar is acceptable, DBCN should work
> > well here.
> 
> ... I prefer to use SBI functionality (in the current case DBCN) as maximum
> as possible so if there is no any reason (and I don't see at the moment it)
> which doesn't allow us to use DBCN here, I would prefer to use DBCN.
> 

Given that Xen on RISC-V is expected to target relatively recent RVA23 hardware,
which should ship with a recent version of OpenSBI, I think you are right that
there is no real need to provide a fallback here.

> If you still want to in the way suggested by TODO then some parts which are
> common between Arm and RISC-V should be moved to common instead of
> introducing them in RISC-V specific folder.
>

I also tried to make the current patch as minimal as possible, but it would
still end up touching quite a few places.

> Let me know which approach you are going to follow. If the current one you
> already introduced then I will start to review it, if you will go SBI-way
> then I prefer to wait for your v2.
> 
> ~ Oleksii
> 

I misunderstood the TODO comment, I thought that would be the preferred
implementation. Therefore, I will switch to using DBCN and send a v2.

Best regards,

Zhang

> > > > 
> > > > This also addresses truncated output observed on SpacemiT K3 when
> > > > switching from early printk to dtuart. Direct UART access lets early
> > > > printk flush the UART after each string before the dtuart driver takes
> > > > over and clear it's FIFO, which cause the truncated uart output.>
> > > > The truncated uart looks like:
> > > > 
> > > >     (XEN) Command line: dtuart=/soc/uart@d4017000:115200/921600 console=dtuart sync_console
> > > >     (XEN) Domain heap initialised
> > > >     (XEN) Booting using Device Tree
> > > >     (XEN) /home/zz/dev/git/xen_stuff/xen/xen/arch/riscv/cpufeature.c:710: SSTC detected; supported for Xen use, but not for guests
> > > >     (XEN) Looking for dtuart at "/soc/uart@d40 __  __            _  _    ____  _____                    _        _     _
> > > >      \ \/ /___ _ __   | || |  |___ \|___ /    _   _ _ __  ___| |_ __ _| |__ | | ___
> > > >       \  // _ \ '_ \  | || |_   __) | |_ \ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
> > > >       /  \  __/ | | | |__   _| / __/ ___) |__| |_| | | | \__ \ || (_| | |_) | |  __/
> > > >      /_/\_\___|_| |_|    |_|(_)_____|____/    \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
> > > > 
> > > >     (XEN) Xen version 4.23-unstable (zz@) (riscv64-linux-gnu-gcc (GCC) 15.1.0) debug=y ubsan=y Sat Sep 26 14:50:31 CST 2026
> > > >     (XEN) Latest ChangeSet: Fri Sep 18 10:11:27 2026 +0800 git:77544a69ea
> > > > 
> > > > Zheng Zhang (1):
> > > >     xen/riscv: replace SBI early console with 8250 UAR
> > > > 
> > > >    xen/arch/riscv/Kconfig.debug              | 53 ++++++++++++++++++++--
> > > >    xen/arch/riscv/configs/tiny64_defconfig   |  2 +
> > > >    xen/arch/riscv/early_printk.c             | 37 +++++++---------
> > > >    xen/arch/riscv/include/asm/early_printk.h | 12 +++++
> > > >    xen/arch/riscv/include/asm/fixmap.h       |  6 ++-
> > > >    xen/arch/riscv/include/asm/sbi.h          |  7 ---
> > > >    xen/arch/riscv/mm.c                       | 41 +++++++++++++----
> > > >    xen/arch/riscv/riscv64/Makefile           |  1 +
> > > >    xen/arch/riscv/riscv64/debug-8250.inc     | 51 +++++++++++++++++++++
> > > >    xen/arch/riscv/riscv64/debug.S            | 54 +++++++++++++++++++++++
> > > >    xen/arch/riscv/sbi.c                      |  5 ---
> > > >    11 files changed, 223 insertions(+), 46 deletions(-)
> > > >    create mode 100644 xen/arch/riscv/riscv64/debug-8250.inc
> > > >    create mode 100644 xen/arch/riscv/riscv64/debug.S
> > > > 
> > > > base-commit: 4c1aba82cff95ab11f7fe4af8965a06703537288
> > 
> 
> 

Re: [PATCH v1 0/1] [RISC-V] replace SBI early console with 8250 UART

[Zhang Zheng]

On Mon, Sep 28, 2026 at 08:53:15PM +0800, Zhang Zheng wrote:
> On Mon, Sep 28, 2026 at 11:31:06AM +0200, Oleksii Kurochko wrote:
> > 
> > 
> > On 9/28/26 10:40 AM, Zhang Zheng wrote:
> > > On Mon, Sep 28, 2026 at 09:38:14AM +0200, Oleksii Kurochko wrote:
> > > > 
> > > > 
> > > > On 9/28/26 4:38 AM, Zhang Zheng wrote:
> > > > > The legacy SBI console extension is planned for deprecation. Replace the
> > > > > RISC-V early printk backend with direct access to 8250 UART MMIO.
> > > > 
> > > > Won't it better just to start to add support of newer SBI? It provides
> > > > pretty good support + faster as it supports passing of string instead of one
> > > > char.
> > > > 
> > > 
> > > Using the newer SBI DBCN extension would indeed result in a smaller change. At
> > > the time, I mainly followed the direction suggested by the TODO and referred
> > > directly to the arm64 implementation, from which most of the code was adapted.
> > 
> > I think TODO was written at that way because I missed DBCN (or it wasn't
> > ratified at that moment). Considering that it is ratified now ...
> > 
> > > 
> > > > Also, I think it will lead to lesser changes.
> > > > 
> > > 
> > > If falling back to SBI console putchar is acceptable, DBCN should work
> > > well here.
> > 
> > ... I prefer to use SBI functionality (in the current case DBCN) as maximum
> > as possible so if there is no any reason (and I don't see at the moment it)
> > which doesn't allow us to use DBCN here, I would prefer to use DBCN.
> > 
> 
> Given that Xen on RISC-V is expected to target relatively recent RVA23 hardware,
> which should ship with a recent version of OpenSBI, I think you are right that
> there is no real need to provide a fallback here.
> 
> > If you still want to in the way suggested by TODO then some parts which are
> > common between Arm and RISC-V should be moved to common instead of
> > introducing them in RISC-V specific folder.
> >
> 
> I also tried to make the current patch as minimal as possible, but it would
> still end up touching quite a few places.
> 
> > Let me know which approach you are going to follow. If the current one you
> > already introduced then I will start to review it, if you will go SBI-way
> > then I prefer to wait for your v2.
> > 
> > ~ Oleksii
> > 
> 
> I misunderstood the TODO comment, I thought that would be the preferred
> implementation. Therefore, I will switch to using DBCN and send a v2.
> 
> Best regards,
> 
> Zhang
> 

Hi Oleksii,

I initially assumed that the DBCN console-write call would wait until the
whole string had been transmitted. After checking the SBI specification
and the Linux implementation, I found that this is not the case.

The DBCN Console Write function is explicitly non-blocking. Linux uses DBCN
through the HVC console driver, so the DBCN backend remains the owner of the
console and the 8250 driver does not subsequently reinitialize the same UART
or clear its FIFO.

On the other hand, when Linux uses an 8250 earlycon, it accesses the UART
directly and waits for UART_LSR_TEMT before the regular 8250 driver takes
over.

The current Xen setup combines these two paths: early printk uses the SBI
console, while the later 8250 driver initializes the same UART. During this
handover, the 8250 driver clears the TX FIFO, which can discard characters
that were accepted by SBI but have not yet been transmitted by the UART.

Therefore, if Xen is going to use the 8250 driver after early printk, I
think the early console should use the same 8250 MMIO path, as Linux does
with 8250 earlycon. This keeps the early-console backend consistent with
the driver that takes ownership of the UART and allows Xen to wait for
UART_LSR_TEMT before reinitialization.

BR

Zhang

Re: [PATCH v1 0/1] [RISC-V] replace SBI early console with 8250 UART

[Oleksii Kurochko]

Hello Zheng,

On 9/29/26 5:10 AM, Zhang Zheng wrote:
> On Mon, Sep 28, 2026 at 08:53:15PM +0800, Zhang Zheng wrote:
>> On Mon, Sep 28, 2026 at 11:31:06AM +0200, Oleksii Kurochko wrote:
>>>
>>>
>>> On 9/28/26 10:40 AM, Zhang Zheng wrote:
>>>> On Mon, Sep 28, 2026 at 09:38:14AM +0200, Oleksii Kurochko wrote:
>>>>>
>>>>>
>>>>> On 9/28/26 4:38 AM, Zhang Zheng wrote:
>>>>>> The legacy SBI console extension is planned for deprecation. Replace the
>>>>>> RISC-V early printk backend with direct access to 8250 UART MMIO.
>>>>>
>>>>> Won't it better just to start to add support of newer SBI? It provides
>>>>> pretty good support + faster as it supports passing of string instead of one
>>>>> char.
>>>>>
>>>>
>>>> Using the newer SBI DBCN extension would indeed result in a smaller change. At
>>>> the time, I mainly followed the direction suggested by the TODO and referred
>>>> directly to the arm64 implementation, from which most of the code was adapted.
>>>
>>> I think TODO was written at that way because I missed DBCN (or it wasn't
>>> ratified at that moment). Considering that it is ratified now ...
>>>
>>>>
>>>>> Also, I think it will lead to lesser changes.
>>>>>
>>>>
>>>> If falling back to SBI console putchar is acceptable, DBCN should work
>>>> well here.
>>>
>>> ... I prefer to use SBI functionality (in the current case DBCN) as maximum
>>> as possible so if there is no any reason (and I don't see at the moment it)
>>> which doesn't allow us to use DBCN here, I would prefer to use DBCN.
>>>
>>
>> Given that Xen on RISC-V is expected to target relatively recent RVA23 hardware,
>> which should ship with a recent version of OpenSBI, I think you are right that
>> there is no real need to provide a fallback here.
>>
>>> If you still want to in the way suggested by TODO then some parts which are
>>> common between Arm and RISC-V should be moved to common instead of
>>> introducing them in RISC-V specific folder.
>>>
>>
>> I also tried to make the current patch as minimal as possible, but it would
>> still end up touching quite a few places.
>>
>>> Let me know which approach you are going to follow. If the current one you
>>> already introduced then I will start to review it, if you will go SBI-way
>>> then I prefer to wait for your v2.
>>>
>>> ~ Oleksii
>>>
>>
>> I misunderstood the TODO comment, I thought that would be the preferred
>> implementation. Therefore, I will switch to using DBCN and send a v2.

I think I didn’t word it in the best way.

For early debug, I think it would be better to use the SBI function. At 
some point, it doesn’t really matter which one we use, SBI 0.1 or DBCN. 
If we switch to using the UART’s MMIO directly, we wouldn’t need to 
change the privilege mode or perform a context switch, so it should be 
faster.

However, considering that the early console is mainly used during 
bring-up, it seems like the overhead of an SBI function call isn’t a big 
price to pay. In return, we could potentially have early printk support 
even for UARTs that aren’t currently supported by Xen.

>>
>> Best regards,
>>
>> Zhang
>>
> 
> Hi Oleksii,
> 
> I initially assumed that the DBCN console-write call would wait until the
> whole string had been transmitted. After checking the SBI specification
> and the Linux implementation, I found that this is not the case.

I think Linux does roughly the same here: its SBI earlycon
calls sbi_debug_console_write() (or something like that) in a loop until 
the whole buffer has been written.

Also note that Linux supports both the legacy SBI v0.1 console_putchar
and DBCN console write for earlycon. It picks DBCN when the firmware
provides it and falls back to v0.1 otherwise (when CONFIG_RISCV_SBI_V01
is enabled). I would really like Xen to do the same rather than drop
SBI v0.1 support. A board might not support DBCN, or might implement 
only the legacy SBI extensions, and we still want console output there. 
So we should keep both.

I'd go further: we probably don't need to add DBCN support at this point.
It would be enough to fix the bug you originally hit with the legacy SBI
call.

Also, in Linux the SBI console is only used as an early (boot) console.
Once the UART driver has probed and registered a real console, printk
switches to it and unregisters the boot console (unless keep_bootcon is
passed). So this switch doesn't cause any issues in Linux, and I don't 
see why it should be a problem in our case either. Switching to DBCN, or 
the approach taken in the current patch, looks to me like it is just 
hiding an issue somewhere else.

> 
> The DBCN Console Write function is explicitly non-blocking. Linux uses DBCN
> through the HVC console driver, so the DBCN backend remains the owner of the
> console and the 8250 driver does not subsequently reinitialize the same UART
> or clear its FIFO.
> 
> On the other hand, when Linux uses an 8250 earlycon, it accesses the UART
> directly and waits for UART_LSR_TEMT before the regular 8250 driver takes
> over.
> 
> The current Xen setup combines these two paths: early printk uses the SBI
> console, while the later 8250 driver initializes the same UART. During this
> handover, the 8250 driver clears the TX FIFO, which can discard characters
> that were accepted by SBI but have not yet been transmitted by the UART.

Isn't a question just doing flush before switch to 8250 so we won't 
loose anything? (and then again why Linux doesn't have such issue 
considering that they have the similar way of work, even without 
virtualization)

> 
> Therefore, if Xen is going to use the 8250 driver after early printk, I
> think the early console should use the same 8250 MMIO path, as Linux does
> with 8250 earlycon. This keeps the early-console backend consistent with
> the driver that takes ownership of the UART and allows Xen to wait for
> UART_LSR_TEMT before reinitialization.

At some point, yes, but then we could lose support for other UARTs that 
OpenSBI could provide out of the box for initial bring-up debugging.

Also, we could have both implementations for early printk (SBI-based and 
MMIO-based), configurable through some option, and allow the user to 
choose which approach to use. But for now, I think we could live with 
the SBI-based implementation (even with support only for old SBI console 
call for a while), as it is more generic, until we actually face a 
performance issue where the MMIO-based approach would start to provide a 
benefit.

~ Oleksii

Re: [PATCH v1 0/1] [RISC-V] replace SBI early console with 8250 UART

[Zhang Zheng]

On Wed, Sep 30, 2026 at 01:22:46PM +0200, Oleksii Kurochko wrote:
> Hello Zheng,
> 
> On 9/29/26 5:10 AM, Zhang Zheng wrote:
> > On Mon, Sep 28, 2026 at 08:53:15PM +0800, Zhang Zheng wrote:
> > > On Mon, Sep 28, 2026 at 11:31:06AM +0200, Oleksii Kurochko wrote:
> > > > 
> > > > 
> > > > On 9/28/26 10:40 AM, Zhang Zheng wrote:
> > > > > On Mon, Sep 28, 2026 at 09:38:14AM +0200, Oleksii Kurochko wrote:
> > > > > > 
> > > > > > 
> > > > > > On 9/28/26 4:38 AM, Zhang Zheng wrote:
> > > > > > > The legacy SBI console extension is planned for deprecation. Replace the
> > > > > > > RISC-V early printk backend with direct access to 8250 UART MMIO.
> > > > > > 
> > > > > > Won't it better just to start to add support of newer SBI? It provides
> > > > > > pretty good support + faster as it supports passing of string instead of one
> > > > > > char.
> > > > > > 
> > > > > 
> > > > > Using the newer SBI DBCN extension would indeed result in a smaller change. At
> > > > > the time, I mainly followed the direction suggested by the TODO and referred
> > > > > directly to the arm64 implementation, from which most of the code was adapted.
> > > > 
> > > > I think TODO was written at that way because I missed DBCN (or it wasn't
> > > > ratified at that moment). Considering that it is ratified now ...
> > > > 
> > > > > 
> > > > > > Also, I think it will lead to lesser changes.
> > > > > > 
> > > > > 
> > > > > If falling back to SBI console putchar is acceptable, DBCN should work
> > > > > well here.
> > > > 
> > > > ... I prefer to use SBI functionality (in the current case DBCN) as maximum
> > > > as possible so if there is no any reason (and I don't see at the moment it)
> > > > which doesn't allow us to use DBCN here, I would prefer to use DBCN.
> > > > 
> > > 
> > > Given that Xen on RISC-V is expected to target relatively recent RVA23 hardware,
> > > which should ship with a recent version of OpenSBI, I think you are right that
> > > there is no real need to provide a fallback here.
> > > 
> > > > If you still want to in the way suggested by TODO then some parts which are
> > > > common between Arm and RISC-V should be moved to common instead of
> > > > introducing them in RISC-V specific folder.
> > > > 
> > > 
> > > I also tried to make the current patch as minimal as possible, but it would
> > > still end up touching quite a few places.
> > > 
> > > > Let me know which approach you are going to follow. If the current one you
> > > > already introduced then I will start to review it, if you will go SBI-way
> > > > then I prefer to wait for your v2.
> > > > 
> > > > ~ Oleksii
> > > > 
> > > 
> > > I misunderstood the TODO comment, I thought that would be the preferred
> > > implementation. Therefore, I will switch to using DBCN and send a v2.
> 
> I think I didn’t word it in the best way.
> 
> For early debug, I think it would be better to use the SBI function. At some
> point, it doesn’t really matter which one we use, SBI 0.1 or DBCN. If we
> switch to using the UART’s MMIO directly, we wouldn’t need to change the
> privilege mode or perform a context switch, so it should be faster.
> 
> However, considering that the early console is mainly used during bring-up,
> it seems like the overhead of an SBI function call isn’t a big price to pay.
> In return, we could potentially have early printk support even for UARTs
> that aren’t currently supported by Xen.
> 
> > > 
> > > Best regards,
> > > 
> > > Zhang
> > > 
> > 
> > Hi Oleksii,
> > 
> > I initially assumed that the DBCN console-write call would wait until the
> > whole string had been transmitted. After checking the SBI specification
> > and the Linux implementation, I found that this is not the case.
> 
> I think Linux does roughly the same here: its SBI earlycon
> calls sbi_debug_console_write() (or something like that) in a loop until the
> whole buffer has been written.
> 
> Also note that Linux supports both the legacy SBI v0.1 console_putchar
> and DBCN console write for earlycon. It picks DBCN when the firmware
> provides it and falls back to v0.1 otherwise (when CONFIG_RISCV_SBI_V01
> is enabled). I would really like Xen to do the same rather than drop
> SBI v0.1 support. A board might not support DBCN, or might implement only
> the legacy SBI extensions, and we still want console output there. So we
> should keep both.
> 
> I'd go further: we probably don't need to add DBCN support at this point.
> It would be enough to fix the bug you originally hit with the legacy SBI
> call.
> 
> Also, in Linux the SBI console is only used as an early (boot) console.
> Once the UART driver has probed and registered a real console, printk
> switches to it and unregisters the boot console (unless keep_bootcon is
> passed). So this switch doesn't cause any issues in Linux, and I don't see
> why it should be a problem in our case either. Switching to DBCN, or the
> approach taken in the current patch, looks to me like it is just hiding an
> issue somewhere else.
> 
> > 
> > The DBCN Console Write function is explicitly non-blocking. Linux uses DBCN
> > through the HVC console driver, so the DBCN backend remains the owner of the
> > console and the 8250 driver does not subsequently reinitialize the same UART
> > or clear its FIFO.
> > 
> > On the other hand, when Linux uses an 8250 earlycon, it accesses the UART
> > directly and waits for UART_LSR_TEMT before the regular 8250 driver takes
> > over.
> > 
> > The current Xen setup combines these two paths: early printk uses the SBI
> > console, while the later 8250 driver initializes the same UART. During this
> > handover, the 8250 driver clears the TX FIFO, which can discard characters
> > that were accepted by SBI but have not yet been transmitted by the UART.
> 
> Isn't a question just doing flush before switch to 8250 so we won't loose
> anything? (and then again why Linux doesn't have such issue considering that
> they have the similar way of work, even without virtualization)
> 
> > 
> > Therefore, if Xen is going to use the 8250 driver after early printk, I
> > think the early console should use the same 8250 MMIO path, as Linux does
> > with 8250 earlycon. This keeps the early-console backend consistent with
> > the driver that takes ownership of the UART and allows Xen to wait for
> > UART_LSR_TEMT before reinitialization.
> 
> At some point, yes, but then we could lose support for other UARTs that
> OpenSBI could provide out of the box for initial bring-up debugging.
> 
> Also, we could have both implementations for early printk (SBI-based and
> MMIO-based), configurable through some option, and allow the user to choose
> which approach to use. But for now, I think we could live with the SBI-based
> implementation (even with support only for old SBI console call for a
> while), as it is more generic, until we actually face a performance issue
> where the MMIO-based approach would start to provide a benefit.
> 
> ~ Oleksii

Hi Oleksii,

Thanks for the clarification and suggestion.

I have sent v2, keeping the existing SBI early console unchanged.  Following
your suggestion, it drains pending TX data before ns16550 reinitializes the
UART.

While bringing up Xen on K3 I also encountered an issue with its
XScale-compatible UART, so v2 includes a separate fix to detect and preserve
the UART_IER_UUE bit.  As a result, v2 now mainly fixes UART handover issues
rather than changing the RISC-V early printk implementation.

I'm not sure whether carrying these fixes as v2 of the original series is the
best approach, so please let me know if you have any concerns.

Zhang

Re: [PATCH v1 0/1] [RISC-V] replace SBI early console with 8250 UART

[Oleksii Kurochko]

On 10/10/26 5:32 AM, Zhang Zheng wrote:
> On Wed, Sep 30, 2026 at 01:22:46PM +0200, Oleksii Kurochko wrote:
>> Hello Zheng,
>>
>> On 9/29/26 5:10 AM, Zhang Zheng wrote:
>>> On Mon, Sep 28, 2026 at 08:53:15PM +0800, Zhang Zheng wrote:
>>>> On Mon, Sep 28, 2026 at 11:31:06AM +0200, Oleksii Kurochko wrote:
>>>>>
>>>>>
>>>>> On 9/28/26 10:40 AM, Zhang Zheng wrote:
>>>>>> On Mon, Sep 28, 2026 at 09:38:14AM +0200, Oleksii Kurochko wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 9/28/26 4:38 AM, Zhang Zheng wrote:
>>>>>>>> The legacy SBI console extension is planned for deprecation. Replace the
>>>>>>>> RISC-V early printk backend with direct access to 8250 UART MMIO.
>>>>>>>
>>>>>>> Won't it better just to start to add support of newer SBI? It provides
>>>>>>> pretty good support + faster as it supports passing of string instead of one
>>>>>>> char.
>>>>>>>
>>>>>>
>>>>>> Using the newer SBI DBCN extension would indeed result in a smaller change. At
>>>>>> the time, I mainly followed the direction suggested by the TODO and referred
>>>>>> directly to the arm64 implementation, from which most of the code was adapted.
>>>>>
>>>>> I think TODO was written at that way because I missed DBCN (or it wasn't
>>>>> ratified at that moment). Considering that it is ratified now ...
>>>>>
>>>>>>
>>>>>>> Also, I think it will lead to lesser changes.
>>>>>>>
>>>>>>
>>>>>> If falling back to SBI console putchar is acceptable, DBCN should work
>>>>>> well here.
>>>>>
>>>>> ... I prefer to use SBI functionality (in the current case DBCN) as maximum
>>>>> as possible so if there is no any reason (and I don't see at the moment it)
>>>>> which doesn't allow us to use DBCN here, I would prefer to use DBCN.
>>>>>
>>>>
>>>> Given that Xen on RISC-V is expected to target relatively recent RVA23 hardware,
>>>> which should ship with a recent version of OpenSBI, I think you are right that
>>>> there is no real need to provide a fallback here.
>>>>
>>>>> If you still want to in the way suggested by TODO then some parts which are
>>>>> common between Arm and RISC-V should be moved to common instead of
>>>>> introducing them in RISC-V specific folder.
>>>>>
>>>>
>>>> I also tried to make the current patch as minimal as possible, but it would
>>>> still end up touching quite a few places.
>>>>
>>>>> Let me know which approach you are going to follow. If the current one you
>>>>> already introduced then I will start to review it, if you will go SBI-way
>>>>> then I prefer to wait for your v2.
>>>>>
>>>>> ~ Oleksii
>>>>>
>>>>
>>>> I misunderstood the TODO comment, I thought that would be the preferred
>>>> implementation. Therefore, I will switch to using DBCN and send a v2.
>>
>> I think I didn’t word it in the best way.
>>
>> For early debug, I think it would be better to use the SBI function. At some
>> point, it doesn’t really matter which one we use, SBI 0.1 or DBCN. If we
>> switch to using the UART’s MMIO directly, we wouldn’t need to change the
>> privilege mode or perform a context switch, so it should be faster.
>>
>> However, considering that the early console is mainly used during bring-up,
>> it seems like the overhead of an SBI function call isn’t a big price to pay.
>> In return, we could potentially have early printk support even for UARTs
>> that aren’t currently supported by Xen.
>>
>>>>
>>>> Best regards,
>>>>
>>>> Zhang
>>>>
>>>
>>> Hi Oleksii,
>>>
>>> I initially assumed that the DBCN console-write call would wait until the
>>> whole string had been transmitted. After checking the SBI specification
>>> and the Linux implementation, I found that this is not the case.
>>
>> I think Linux does roughly the same here: its SBI earlycon
>> calls sbi_debug_console_write() (or something like that) in a loop until the
>> whole buffer has been written.
>>
>> Also note that Linux supports both the legacy SBI v0.1 console_putchar
>> and DBCN console write for earlycon. It picks DBCN when the firmware
>> provides it and falls back to v0.1 otherwise (when CONFIG_RISCV_SBI_V01
>> is enabled). I would really like Xen to do the same rather than drop
>> SBI v0.1 support. A board might not support DBCN, or might implement only
>> the legacy SBI extensions, and we still want console output there. So we
>> should keep both.
>>
>> I'd go further: we probably don't need to add DBCN support at this point.
>> It would be enough to fix the bug you originally hit with the legacy SBI
>> call.
>>
>> Also, in Linux the SBI console is only used as an early (boot) console.
>> Once the UART driver has probed and registered a real console, printk
>> switches to it and unregisters the boot console (unless keep_bootcon is
>> passed). So this switch doesn't cause any issues in Linux, and I don't see
>> why it should be a problem in our case either. Switching to DBCN, or the
>> approach taken in the current patch, looks to me like it is just hiding an
>> issue somewhere else.
>>
>>>
>>> The DBCN Console Write function is explicitly non-blocking. Linux uses DBCN
>>> through the HVC console driver, so the DBCN backend remains the owner of the
>>> console and the 8250 driver does not subsequently reinitialize the same UART
>>> or clear its FIFO.
>>>
>>> On the other hand, when Linux uses an 8250 earlycon, it accesses the UART
>>> directly and waits for UART_LSR_TEMT before the regular 8250 driver takes
>>> over.
>>>
>>> The current Xen setup combines these two paths: early printk uses the SBI
>>> console, while the later 8250 driver initializes the same UART. During this
>>> handover, the 8250 driver clears the TX FIFO, which can discard characters
>>> that were accepted by SBI but have not yet been transmitted by the UART.
>>
>> Isn't a question just doing flush before switch to 8250 so we won't loose
>> anything? (and then again why Linux doesn't have such issue considering that
>> they have the similar way of work, even without virtualization)
>>
>>>
>>> Therefore, if Xen is going to use the 8250 driver after early printk, I
>>> think the early console should use the same 8250 MMIO path, as Linux does
>>> with 8250 earlycon. This keeps the early-console backend consistent with
>>> the driver that takes ownership of the UART and allows Xen to wait for
>>> UART_LSR_TEMT before reinitialization.
>>
>> At some point, yes, but then we could lose support for other UARTs that
>> OpenSBI could provide out of the box for initial bring-up debugging.
>>
>> Also, we could have both implementations for early printk (SBI-based and
>> MMIO-based), configurable through some option, and allow the user to choose
>> which approach to use. But for now, I think we could live with the SBI-based
>> implementation (even with support only for old SBI console call for a
>> while), as it is more generic, until we actually face a performance issue
>> where the MMIO-based approach would start to provide a benefit.
>>
>> ~ Oleksii
> 
> Hi Oleksii,

Hello Zheng,

> 
> Thanks for the clarification and suggestion.
> 
> I have sent v2, keeping the existing SBI early console unchanged.  Following
> your suggestion, it drains pending TX data before ns16550 reinitializes the
> UART.

I will check your v2 during this week.

> 
> While bringing up Xen on K3 I also encountered an issue with its
> XScale-compatible UART, so v2 includes a separate fix to detect and preserve
> the UART_IER_UUE bit.  As a result, v2 now mainly fixes UART handover issues
> rather than changing the RISC-V early printk implementation.

Sounds good to me!

> 
> I'm not sure whether carrying these fixes as v2 of the original series is the
> best approach, so please let me know if you have any concerns.

I think I don't have any concern but probably it would be better to say 
that it is v1 as patches don't touch RISC-V specific code anymore. But 
you mentioned basically why it is v2 in cover letter and it is okay to 
me, at least.

Thanks for v2!

~ Oleksii