* [PATCH v2 1/4] serial: Add Goldfish TTY driver
2025-12-26 17:53 [PATCH v2 0/4] m68k: Add support for QEMU virt machine Kuan-Wei Chiu
@ 2025-12-26 17:53 ` Kuan-Wei Chiu
2025-12-27 2:07 ` Yao Zi
2025-12-26 17:53 ` [PATCH v2 2/4] m68k: Add support for M68040 CPU Kuan-Wei Chiu
` (2 subsequent siblings)
3 siblings, 1 reply; 19+ messages in thread
From: Kuan-Wei Chiu @ 2025-12-26 17:53 UTC (permalink / raw)
To: alison.wang, angelo
Cc: trini, me, daniel, jserv, eleanor15x, u-boot, Kuan-Wei Chiu
Add support for the Google Goldfish TTY serial device. This virtual
device is commonly used in QEMU virtual machines (such as the m68k
virt machine) and Android emulators.
The driver implements basic console output and input polling using the
Goldfish MMIO interface.
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
---
Changes in v2:
- Update SPDX license identifier to GPL-2.0-or-later.
- Sort header inclusions alphabetically.
- Move RX buffer into goldfish_tty_priv instead of using a static buffer.
- Make sure getc only read a single byte at a time.
MAINTAINERS | 6 ++
drivers/serial/Kconfig | 8 +++
drivers/serial/Makefile | 1 +
drivers/serial/serial_goldfish.c | 104 +++++++++++++++++++++++++++++++
include/goldfish_tty.h | 18 ++++++
5 files changed, 137 insertions(+)
create mode 100644 drivers/serial/serial_goldfish.c
create mode 100644 include/goldfish_tty.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 6ce0bbce13d..da4a6e4d518 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1259,6 +1259,12 @@ S: Maintained
F: drivers/misc/gsc.c
F: include/gsc.h
+GOLDFISH SERIAL DRIVER
+M: Kuan-Wei Chiu <visitorckw@gmail.com>
+S: Maintained
+F: drivers/serial/serial_goldfish.c
+F: include/goldfish_tty.h
+
I2C
M: Heiko Schocher <hs@nabladev.com>
S: Maintained
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 371d7aa5bba..b84cb9ec781 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -1193,4 +1193,12 @@ config SYS_SDMR
depends on MPC8XX_CONS
default 0x0
+config SERIAL_GOLDFISH
+ bool "Goldfish TTY support"
+ depends on DM_SERIAL
+ help
+ Select this to enable support for the Goldfish TTY serial port.
+ This virtual device is commonly used by QEMU virtual machines
+ (e.g. m68k virt) for console output.
+
endif
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 8eaae62b0fc..fe8d23be512 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -63,3 +63,4 @@ obj-$(CONFIG_XTENSA_SEMIHOSTING_SERIAL) += serial_xtensa_semihosting.o
obj-$(CONFIG_S5P4418_PL011_SERIAL) += serial_s5p4418_pl011.o
obj-$(CONFIG_UART4_SERIAL) += serial_adi_uart4.o
+obj-$(CONFIG_SERIAL_GOLDFISH) += serial_goldfish.o
diff --git a/drivers/serial/serial_goldfish.c b/drivers/serial/serial_goldfish.c
new file mode 100644
index 00000000000..ce5bff6bf4c
--- /dev/null
+++ b/drivers/serial/serial_goldfish.c
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2025, Kuan-Wei Chiu <visitorckw@gmail.com>
+ * Goldfish TTY driver for U-Boot
+ */
+
+#include <asm/io.h>
+#include <dm.h>
+#include <goldfish_tty.h>
+#include <linux/types.h>
+#include <serial.h>
+
+/* Goldfish TTY Register Offsets */
+#define GOLDFISH_TTY_PUT_CHAR 0x00
+#define GOLDFISH_TTY_BYTES_READY 0x04
+#define GOLDFISH_TTY_CMD 0x08
+#define GOLDFISH_TTY_DATA_PTR 0x10
+#define GOLDFISH_TTY_DATA_LEN 0x14
+#define GOLDFISH_TTY_DATA_PTR_HIGH 0x18
+#define GOLDFISH_TTY_VERSION 0x20
+
+/* Commands */
+#define CMD_WRITE_BUFFER 2
+#define CMD_READ_BUFFER 3
+
+struct goldfish_tty_priv {
+ void __iomem *base;
+ u8 rx_buf;
+};
+
+static int goldfish_serial_getc(struct udevice *dev)
+{
+ struct goldfish_tty_priv *priv = dev_get_priv(dev);
+ unsigned long base = (unsigned long)priv->base;
+ unsigned long paddr;
+ u32 count;
+
+ count = __raw_readl((void *)(base + GOLDFISH_TTY_BYTES_READY));
+ if (count == 0)
+ return -EAGAIN;
+
+ paddr = virt_to_phys((void *)&priv->rx_buf);
+
+ __raw_writel(0, (void *)(base + GOLDFISH_TTY_DATA_PTR_HIGH));
+ __raw_writel(paddr, (void *)(base + GOLDFISH_TTY_DATA_PTR));
+ __raw_writel(1, (void *)(base + GOLDFISH_TTY_DATA_LEN));
+
+ __raw_writel(CMD_READ_BUFFER, (void *)(base + GOLDFISH_TTY_CMD));
+
+ return priv->rx_buf;
+}
+
+static int goldfish_serial_putc(struct udevice *dev, const char ch)
+{
+ struct goldfish_tty_priv *priv = dev_get_priv(dev);
+
+ __raw_writel(ch, priv->base + GOLDFISH_TTY_PUT_CHAR);
+
+ return 0;
+}
+
+static int goldfish_serial_pending(struct udevice *dev, bool input)
+{
+ struct goldfish_tty_priv *priv = dev_get_priv(dev);
+
+ if (input)
+ return __raw_readl(priv->base + GOLDFISH_TTY_BYTES_READY);
+
+ return 0;
+}
+
+static int goldfish_serial_probe(struct udevice *dev)
+{
+ struct goldfish_tty_priv *priv = dev_get_priv(dev);
+ struct goldfish_tty_plat *plat = dev_get_plat(dev);
+
+ if (!plat)
+ return -EINVAL;
+
+ priv->base = plat->base;
+
+ return 0;
+}
+
+static const struct dm_serial_ops goldfish_serial_ops = {
+ .putc = goldfish_serial_putc,
+ .pending = goldfish_serial_pending,
+ .getc = goldfish_serial_getc,
+};
+
+static const struct udevice_id goldfish_serial_ids[] = {
+ { .compatible = "google,goldfish-tty" },
+ { }
+};
+
+U_BOOT_DRIVER(serial_goldfish) = {
+ .name = "serial_goldfish",
+ .id = UCLASS_SERIAL,
+ .of_match = goldfish_serial_ids,
+ .probe = goldfish_serial_probe,
+ .ops = &goldfish_serial_ops,
+ .priv_auto = sizeof(struct goldfish_tty_priv),
+ .flags = DM_FLAG_PRE_RELOC,
+};
diff --git a/include/goldfish_tty.h b/include/goldfish_tty.h
new file mode 100644
index 00000000000..8777da4942d
--- /dev/null
+++ b/include/goldfish_tty.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2025, Kuan-Wei Chiu <visitorckw@gmail.com>
+ */
+
+#ifndef _GOLDFISH_TTY_H_
+#define _GOLDFISH_TTY_H_
+
+#include <linux/types.h>
+
+/* Platform data for the Goldfish TTY driver
+ * Used to pass hardware base address from Board to Driver
+ */
+struct goldfish_tty_plat {
+ void __iomem *base;
+};
+
+#endif /* _GOLDFISH_TTY_H_ */
--
2.52.0.358.g0dd7633a29-goog
^ permalink raw reply related [flat|nested] 19+ messages in thread* Re: [PATCH v2 1/4] serial: Add Goldfish TTY driver
2025-12-26 17:53 ` [PATCH v2 1/4] serial: Add Goldfish TTY driver Kuan-Wei Chiu
@ 2025-12-27 2:07 ` Yao Zi
2025-12-27 14:06 ` Kuan-Wei Chiu
0 siblings, 1 reply; 19+ messages in thread
From: Yao Zi @ 2025-12-27 2:07 UTC (permalink / raw)
To: Kuan-Wei Chiu, alison.wang, angelo
Cc: trini, daniel, jserv, eleanor15x, u-boot
On Fri, Dec 26, 2025 at 05:53:57PM +0000, Kuan-Wei Chiu wrote:
> Add support for the Google Goldfish TTY serial device. This virtual
> device is commonly used in QEMU virtual machines (such as the m68k
> virt machine) and Android emulators.
>
> The driver implements basic console output and input polling using the
> Goldfish MMIO interface.
>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> ---
> Changes in v2:
> - Update SPDX license identifier to GPL-2.0-or-later.
> - Sort header inclusions alphabetically.
> - Move RX buffer into goldfish_tty_priv instead of using a static buffer.
> - Make sure getc only read a single byte at a time.
>
> MAINTAINERS | 6 ++
> drivers/serial/Kconfig | 8 +++
> drivers/serial/Makefile | 1 +
> drivers/serial/serial_goldfish.c | 104 +++++++++++++++++++++++++++++++
> include/goldfish_tty.h | 18 ++++++
> 5 files changed, 137 insertions(+)
> create mode 100644 drivers/serial/serial_goldfish.c
> create mode 100644 include/goldfish_tty.h
...
> diff --git a/drivers/serial/serial_goldfish.c b/drivers/serial/serial_goldfish.c
> new file mode 100644
> index 00000000000..ce5bff6bf4c
> --- /dev/null
> +++ b/drivers/serial/serial_goldfish.c
> @@ -0,0 +1,104 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2025, Kuan-Wei Chiu <visitorckw@gmail.com>
> + * Goldfish TTY driver for U-Boot
> + */
> +
> +#include <asm/io.h>
> +#include <dm.h>
> +#include <goldfish_tty.h>
> +#include <linux/types.h>
> +#include <serial.h>
> +
> +/* Goldfish TTY Register Offsets */
> +#define GOLDFISH_TTY_PUT_CHAR 0x00
> +#define GOLDFISH_TTY_BYTES_READY 0x04
> +#define GOLDFISH_TTY_CMD 0x08
> +#define GOLDFISH_TTY_DATA_PTR 0x10
> +#define GOLDFISH_TTY_DATA_LEN 0x14
> +#define GOLDFISH_TTY_DATA_PTR_HIGH 0x18
> +#define GOLDFISH_TTY_VERSION 0x20
> +
> +/* Commands */
> +#define CMD_WRITE_BUFFER 2
> +#define CMD_READ_BUFFER 3
> +
> +struct goldfish_tty_priv {
> + void __iomem *base;
> + u8 rx_buf;
> +};
> +
> +static int goldfish_serial_getc(struct udevice *dev)
> +{
> + struct goldfish_tty_priv *priv = dev_get_priv(dev);
> + unsigned long base = (unsigned long)priv->base;
> + unsigned long paddr;
> + u32 count;
> +
> + count = __raw_readl((void *)(base + GOLDFISH_TTY_BYTES_READY));
I think it's okay to do pointer arithmetic directly against priv->base
in GNU C, right? In which case void * is treated like char *.
If I'm correct, variable base could be dropped, and we could avoid some
casts here and below.
> + if (count == 0)
> + return -EAGAIN;
> +
> + paddr = virt_to_phys((void *)&priv->rx_buf);
> +
> + __raw_writel(0, (void *)(base + GOLDFISH_TTY_DATA_PTR_HIGH));
> + __raw_writel(paddr, (void *)(base + GOLDFISH_TTY_DATA_PTR));
> + __raw_writel(1, (void *)(base + GOLDFISH_TTY_DATA_LEN));
> +
> + __raw_writel(CMD_READ_BUFFER, (void *)(base + GOLDFISH_TTY_CMD));
> +
> + return priv->rx_buf;
> +}
Regards,
Yao Zi
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH v2 1/4] serial: Add Goldfish TTY driver
2025-12-27 2:07 ` Yao Zi
@ 2025-12-27 14:06 ` Kuan-Wei Chiu
0 siblings, 0 replies; 19+ messages in thread
From: Kuan-Wei Chiu @ 2025-12-27 14:06 UTC (permalink / raw)
To: Yao Zi; +Cc: alison.wang, angelo, trini, daniel, jserv, eleanor15x, u-boot
Hi Yao,
On Sat, Dec 27, 2025 at 02:07:47AM +0000, Yao Zi wrote:
> On Fri, Dec 26, 2025 at 05:53:57PM +0000, Kuan-Wei Chiu wrote:
> > Add support for the Google Goldfish TTY serial device. This virtual
> > device is commonly used in QEMU virtual machines (such as the m68k
> > virt machine) and Android emulators.
> >
> > The driver implements basic console output and input polling using the
> > Goldfish MMIO interface.
> >
> > Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> > ---
> > Changes in v2:
> > - Update SPDX license identifier to GPL-2.0-or-later.
> > - Sort header inclusions alphabetically.
> > - Move RX buffer into goldfish_tty_priv instead of using a static buffer.
> > - Make sure getc only read a single byte at a time.
> >
> > MAINTAINERS | 6 ++
> > drivers/serial/Kconfig | 8 +++
> > drivers/serial/Makefile | 1 +
> > drivers/serial/serial_goldfish.c | 104 +++++++++++++++++++++++++++++++
> > include/goldfish_tty.h | 18 ++++++
> > 5 files changed, 137 insertions(+)
> > create mode 100644 drivers/serial/serial_goldfish.c
> > create mode 100644 include/goldfish_tty.h
>
> ...
>
> > diff --git a/drivers/serial/serial_goldfish.c b/drivers/serial/serial_goldfish.c
> > new file mode 100644
> > index 00000000000..ce5bff6bf4c
> > --- /dev/null
> > +++ b/drivers/serial/serial_goldfish.c
> > @@ -0,0 +1,104 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (C) 2025, Kuan-Wei Chiu <visitorckw@gmail.com>
> > + * Goldfish TTY driver for U-Boot
> > + */
> > +
> > +#include <asm/io.h>
> > +#include <dm.h>
> > +#include <goldfish_tty.h>
> > +#include <linux/types.h>
> > +#include <serial.h>
> > +
> > +/* Goldfish TTY Register Offsets */
> > +#define GOLDFISH_TTY_PUT_CHAR 0x00
> > +#define GOLDFISH_TTY_BYTES_READY 0x04
> > +#define GOLDFISH_TTY_CMD 0x08
> > +#define GOLDFISH_TTY_DATA_PTR 0x10
> > +#define GOLDFISH_TTY_DATA_LEN 0x14
> > +#define GOLDFISH_TTY_DATA_PTR_HIGH 0x18
> > +#define GOLDFISH_TTY_VERSION 0x20
> > +
> > +/* Commands */
> > +#define CMD_WRITE_BUFFER 2
> > +#define CMD_READ_BUFFER 3
> > +
> > +struct goldfish_tty_priv {
> > + void __iomem *base;
> > + u8 rx_buf;
> > +};
> > +
> > +static int goldfish_serial_getc(struct udevice *dev)
> > +{
> > + struct goldfish_tty_priv *priv = dev_get_priv(dev);
> > + unsigned long base = (unsigned long)priv->base;
> > + unsigned long paddr;
> > + u32 count;
> > +
> > + count = __raw_readl((void *)(base + GOLDFISH_TTY_BYTES_READY));
>
> I think it's okay to do pointer arithmetic directly against priv->base
> in GNU C, right? In which case void * is treated like char *.
>
> If I'm correct, variable base could be dropped, and we could avoid some
> casts here and below.
Agreed.
While standard C doesn't allow it, GNU C does support arithmetic on
void *. Doing this directly makes the code look much cleaner.
Thanks for the feedback, I will update this in v3.
Regards,
Kuan-Wei
>
> > + if (count == 0)
> > + return -EAGAIN;
> > +
> > + paddr = virt_to_phys((void *)&priv->rx_buf);
> > +
> > + __raw_writel(0, (void *)(base + GOLDFISH_TTY_DATA_PTR_HIGH));
> > + __raw_writel(paddr, (void *)(base + GOLDFISH_TTY_DATA_PTR));
> > + __raw_writel(1, (void *)(base + GOLDFISH_TTY_DATA_LEN));
> > +
> > + __raw_writel(CMD_READ_BUFFER, (void *)(base + GOLDFISH_TTY_CMD));
> > +
> > + return priv->rx_buf;
> > +}
>
> Regards,
> Yao Zi
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v2 2/4] m68k: Add support for M68040 CPU
2025-12-26 17:53 [PATCH v2 0/4] m68k: Add support for QEMU virt machine Kuan-Wei Chiu
2025-12-26 17:53 ` [PATCH v2 1/4] serial: Add Goldfish TTY driver Kuan-Wei Chiu
@ 2025-12-26 17:53 ` Kuan-Wei Chiu
2025-12-28 1:28 ` Daniel Palmer
2025-12-26 17:53 ` [PATCH v2 3/4] board: Add QEMU m68k virt board support Kuan-Wei Chiu
2025-12-26 17:54 ` [PATCH v2 4/4] CI: Add test jobs for QEMU m68k virt machine Kuan-Wei Chiu
3 siblings, 1 reply; 19+ messages in thread
From: Kuan-Wei Chiu @ 2025-12-26 17:53 UTC (permalink / raw)
To: alison.wang, angelo
Cc: trini, me, daniel, jserv, eleanor15x, u-boot, Kuan-Wei Chiu
Add support for the Motorola 68040 architecture. Currently, m68k
support in U-Boot is primarily focused on ColdFire variants. Introduce
the necessary infrastructure to support the classic M680x0 series,
specifically targeting the M68040 as emulated by QEMU.
The implementation includes exception vectors, early startup code, and
minimal CPU initialization and relocation stubs. It also defines the
standard m68k boot information structure used for passing hardware
information to the operating system. To ensure compatibility, ColdFire-
specific library objects such as cache and interrupt handling are
excluded from the build when M68040 is selected.
Additionally, apply a specific workaround during the early memory
reservation stage. Use a manual loop to clear global data instead of
the standard memset() function, as utilizing memset() at this point was
observed to cause a hang on the QEMU platform.
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
---
Changes in v2:
- Update SPDX license identifier to GPL-2.0-or-later.
- Sort header inclusions alphabetically.
- Separate MAINTAINERS entry for the M680x0 architecture.
- Fix tabs vs spaces in Kconfig.
- Rename arch/m68k/cpu/m68040 to arch/m68k/cpu/m680x0 to separate the
architecture family from the specific CPU model.
- Introduce M680x0 Kconfig symbol for the architecture family, selected
by M68040.
MAINTAINERS | 6 +++
arch/m68k/Kconfig | 16 +++++++
arch/m68k/Makefile | 1 +
arch/m68k/config.mk | 10 ++++-
arch/m68k/cpu/m680x0/Makefile | 6 +++
arch/m68k/cpu/m680x0/cpu.c | 77 ++++++++++++++++++++++++++++++++
arch/m68k/cpu/m680x0/start.S | 73 ++++++++++++++++++++++++++++++
arch/m68k/cpu/m680x0/u-boot.lds | 47 +++++++++++++++++++
arch/m68k/include/asm/bootinfo.h | 31 +++++++++++++
arch/m68k/lib/Makefile | 9 ++--
10 files changed, 268 insertions(+), 8 deletions(-)
create mode 100644 arch/m68k/cpu/m680x0/Makefile
create mode 100644 arch/m68k/cpu/m680x0/cpu.c
create mode 100644 arch/m68k/cpu/m680x0/start.S
create mode 100644 arch/m68k/cpu/m680x0/u-boot.lds
create mode 100644 arch/m68k/include/asm/bootinfo.h
diff --git a/MAINTAINERS b/MAINTAINERS
index da4a6e4d518..d0ae9134551 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1306,6 +1306,12 @@ F: lib/getopt.c
F: test/log/
F: test/py/tests/test_log.py
+M680X0 ARCHITECTURE
+M: Kuan-Wei Chiu <visitorckw@gmail.com>
+S: Maintained
+F: arch/m68k/cpu/m680x0/
+F: arch/m68k/include/asm/bootinfo.h
+
MALI DISPLAY PROCESSORS
M: Liviu Dudau <liviu.dudau@foss.arm.com>
S: Supported
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 8ade6f7b9d1..de7c673c376 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -56,6 +56,9 @@ config MCF5441x
select DM_SERIAL
bool
+config M680x0
+ bool
+
# processor type
config M5208
bool
@@ -110,6 +113,10 @@ config M54418
bool
select MCF5441x
+config M68040
+ bool
+ select M680x0
+
# peripherals
config CF_DSPI
bool
@@ -178,6 +185,15 @@ config TARGET_STMARK2
endchoice
+config SYS_CPU
+ string
+ default "mcf52x2" if MCF52x2
+ default "mcf523x" if MCF523x
+ default "mcf530x" if MCF530x
+ default "mcf532x" if MCF532x
+ default "mcf5445x" if MCF5445x
+ default "m680x0" if M680x0
+
source "board/BuS/eb_cpu5282/Kconfig"
source "board/cobra5272/Kconfig"
source "board/freescale/m5208evbe/Kconfig"
diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile
index 4a7960bbeb4..bb57cf9ac63 100644
--- a/arch/m68k/Makefile
+++ b/arch/m68k/Makefile
@@ -17,6 +17,7 @@ cpuflags-$(CONFIG_M5307) := -mcpu=5307
cpuflags-$(CONFIG_MCF5301x) := -mcpu=53015 -fPIC
cpuflags-$(CONFIG_MCF532x) := -mcpu=5329 -fPIC
cpuflags-$(CONFIG_MCF5441x) := -mcpu=54418 -fPIC
+cpuflags-$(CONFIG_M68040) := -mcpu=68040 -fno-pic
PLATFORM_CPPFLAGS += $(cpuflags-y)
diff --git a/arch/m68k/config.mk b/arch/m68k/config.mk
index 643b7d1d35d..458953f9712 100644
--- a/arch/m68k/config.mk
+++ b/arch/m68k/config.mk
@@ -3,8 +3,14 @@
# (C) Copyright 2000-2002
# Wolfgang Denk, DENX Software Engineering, wd@denx.de.
-PLATFORM_CPPFLAGS += -D__M68K__ -fPIC
+PLATFORM_CPPFLAGS += -D__M68K__
+ifneq ($(CONFIG_M680x0),y)
+PLATFORM_CPPFLAGS += -fPIC
+endif
KBUILD_LDFLAGS += -n -pie
PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections
-PLATFORM_RELFLAGS += -ffixed-d7 -msep-data
+PLATFORM_RELFLAGS += -ffixed-d7
+ifneq ($(CONFIG_M680x0),y)
+PLATFORM_RELFLAGS += -msep-data
+endif
LDFLAGS_FINAL += --gc-sections -pie
diff --git a/arch/m68k/cpu/m680x0/Makefile b/arch/m68k/cpu/m680x0/Makefile
new file mode 100644
index 00000000000..f6e0c9a46c0
--- /dev/null
+++ b/arch/m68k/cpu/m680x0/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2025, Kuan-Wei Chiu <visitorckw@gmail.com>
+
+extra-y += start.o
+obj-y += cpu.o
diff --git a/arch/m68k/cpu/m680x0/cpu.c b/arch/m68k/cpu/m680x0/cpu.c
new file mode 100644
index 00000000000..15e0c30980a
--- /dev/null
+++ b/arch/m68k/cpu/m680x0/cpu.c
@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * CPU specific code for m68040
+ *
+ * Copyright (C) 2025, Kuan-Wei Chiu <visitorckw@gmail.com>
+ */
+
+#include <asm/global_data.h>
+#include <config.h>
+#include <cpu_func.h>
+#include <init.h>
+#include <linux/types.h>
+#include <stdio.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+void m68k_virt_init_reserve(ulong base)
+{
+ struct global_data *gd_ptr = (struct global_data *)base;
+ char *p = (char *)gd_ptr;
+ unsigned int i;
+
+ /* FIXME: usage of memset() here caused a hang on QEMU m68k virt. */
+ for (i = 0; i < sizeof(*gd_ptr); i++)
+ p[i] = 0;
+
+ gd = gd_ptr;
+
+ gd->malloc_base = base + sizeof(*gd_ptr);
+}
+
+int print_cpuinfo(void)
+{
+ puts("CPU: M68040 (QEMU Virt)\n");
+ return 0;
+}
+
+int get_clocks(void)
+{
+ return 0;
+}
+
+int cpu_init_r(void)
+{
+ return 0;
+}
+
+/*
+ * Relocation Stub
+ * We skip actual relocation for this QEMU bring-up and jump directly
+ * to board_init_r.
+ */
+
+void relocate_code(ulong sp, struct global_data *new_gd, ulong relocaddr)
+{
+ board_init_r(new_gd, relocaddr);
+}
+
+/* Stubs for Standard Facilities (Cache, Interrupts, Timer) */
+
+int disable_interrupts(void) { return 0; }
+void enable_interrupts(void) { return; }
+int interrupt_init(void) { return 0; }
+
+void icache_enable(void) {}
+void icache_disable(void) {}
+int icache_status(void) { return 0; }
+void dcache_enable(void) {}
+void dcache_disable(void) {}
+int dcache_status(void) { return 0; }
+void flush_cache(unsigned long start, unsigned long size) {}
+void flush_dcache_range(unsigned long start, unsigned long stop) {}
+
+int timer_init(void) { return 0; }
+unsigned long timer_read_counter(void) { return 0; }
+ulong get_tbclk(void) { return 1000000; }
+void __udelay(unsigned long usec) {}
diff --git a/arch/m68k/cpu/m680x0/start.S b/arch/m68k/cpu/m680x0/start.S
new file mode 100644
index 00000000000..0802ca1fca2
--- /dev/null
+++ b/arch/m68k/cpu/m680x0/start.S
@@ -0,0 +1,73 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Startup code for m68040
+ *
+ * Copyright (C) 2025, Kuan-Wei Chiu <visitorckw@gmail.com>
+ */
+
+#include <asm-offsets.h>
+#include <config.h>
+#include <linux/linkage.h>
+
+.section .text
+
+/*
+ * Vector Table
+ * m68k uses the first 1KB for the exception vector table.
+ */
+.balign 4
+.global _vectors
+_vectors:
+ .long CFG_SYS_INIT_SP_ADDR /* 0x00: Initial SP */
+ .long _start /* 0x04: Initial PC (Reset) */
+ .long _fault /* 0x08: Bus Error */
+ .long _fault /* 0x0C: Address Error */
+ .long _fault /* 0x10: Illegal Instruction */
+ .long _fault /* 0x14: Zero Divide */
+ .long _fault /* 0x18: CHK */
+ .long _fault /* 0x1C: TRAPV */
+ .long _fault /* 0x20: Privilege */
+ .long _fault /* 0x24: Trace */
+ .long _fault /* 0x28: Line 1010 */
+ .long _fault /* 0x2C: Line 1111 */
+ .fill 0x400 - (.-_vectors), 1, 0
+
+/*
+ * Entry Point
+ */
+ENTRY(_start)
+ /* Disable Interrupts */
+ move.w #0x2700, %sr
+
+ /* Setup initial stack pointer */
+ move.l #CFG_SYS_INIT_SP_ADDR, %sp
+
+ /*
+ * Allocate Global Data (GD)
+ * board_init_f_alloc_reserve(top) returns the new top of stack in %d0
+ */
+ move.l %sp, -(%sp)
+ bsr.l board_init_f_alloc_reserve
+ addq.l #4, %sp
+
+ /* Update Stack Pointer and set GD register */
+ move.l %d0, %sp
+ move.l %d0, %d7 /* %d7 is the gd register */
+
+ /* Initialize Reserved Memory. */
+ move.l %d0, -(%sp)
+ bsr.l m68k_virt_init_reserve
+ addq.l #4, %sp
+
+ /* Enter board_init_f(0) */
+ clr.l -(%sp)
+ bsr.l board_init_f
+ addq.l #4, %sp
+
+ /* Should not return */
+hang:
+ bra.s hang
+ENDPROC(_start)
+
+_fault:
+ bra.s _fault
diff --git a/arch/m68k/cpu/m680x0/u-boot.lds b/arch/m68k/cpu/m680x0/u-boot.lds
new file mode 100644
index 00000000000..ae102c32833
--- /dev/null
+++ b/arch/m68k/cpu/m680x0/u-boot.lds
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Linker Script for m68040
+ *
+ * Copyright (C) 2025, Kuan-Wei Chiu <visitorckw@gmail.com>
+ */
+
+OUTPUT_ARCH(m68k)
+ENTRY(_start)
+
+SECTIONS
+{
+ . = 0x00000000;
+ __text_start = .;
+
+ .text :
+ {
+ arch/m68k/cpu/m680x0/start.o (.text*)
+ *(.text*)
+ }
+
+ . = ALIGN(16);
+ .rodata : { *(.rodata*) }
+
+ . = ALIGN(16);
+ .data : { *(.data*) }
+
+ . = ALIGN(4);
+ .u_boot_list : {
+ KEEP(*(SORT(*u_boot_list*)));
+ }
+
+ . = ALIGN(4);
+ __image_copy_end = .;
+ __init_end = .;
+
+ . = ALIGN(16);
+ __bss_start = .;
+ .bss :
+ {
+ *(.bss*)
+ . = ALIGN(16);
+ }
+ __bss_end = .;
+
+ _end = .;
+}
diff --git a/arch/m68k/include/asm/bootinfo.h b/arch/m68k/include/asm/bootinfo.h
new file mode 100644
index 00000000000..3d2ec818257
--- /dev/null
+++ b/arch/m68k/include/asm/bootinfo.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2025, Kuan-Wei Chiu <visitorckw@gmail.com>
+ *
+ * Definitions for the m68k bootinfo interface.
+ */
+
+#ifndef _ASM_M68K_BOOTINFO_H
+#define _ASM_M68K_BOOTINFO_H
+
+#ifndef __ASSEMBLY__
+
+struct bi_record {
+ unsigned short tag; /* tag ID */
+ unsigned short size; /* size of record (in bytes) */
+ unsigned long data[0]; /* data */
+};
+
+#endif /* __ASSEMBLY__ */
+
+/* Bootinfo Tag IDs */
+#define BI_LAST 0x0000
+#define BI_MACHTYPE 0x0001
+#define BI_CPUTYPE 0x0002
+#define BI_FPUTYPE 0x0003
+#define BI_MMUTYPE 0x0004
+#define BI_MEMCHUNK 0x0005
+#define BI_RAMDISK 0x0006
+#define BI_COMMAND_LINE 0x0007
+
+#endif /* _ASM_M68K_BOOTINFO_H */
diff --git a/arch/m68k/lib/Makefile b/arch/m68k/lib/Makefile
index 6e1fd938f52..e62de51f260 100644
--- a/arch/m68k/lib/Makefile
+++ b/arch/m68k/lib/Makefile
@@ -7,10 +7,7 @@
## if the user asked for it
lib-$(CONFIG_USE_PRIVATE_LIBGCC) += lshrdi3.o muldi3.o ashldi3.o ashrdi3.o
-obj-y += bdinfo.o
obj-$(CONFIG_CMD_BOOTM) += bootm.o
-obj-y += cache.o
-obj-y += interrupts.o
-obj-y += time.o
-obj-y += traps.o
-obj-y += fec.o
+ifndef CONFIG_M680x0
+obj-y += cache.o interrupts.o time.o traps.o bdinfo.o fec.o
+endif
--
2.52.0.358.g0dd7633a29-goog
^ permalink raw reply related [flat|nested] 19+ messages in thread* Re: [PATCH v2 2/4] m68k: Add support for M68040 CPU
2025-12-26 17:53 ` [PATCH v2 2/4] m68k: Add support for M68040 CPU Kuan-Wei Chiu
@ 2025-12-28 1:28 ` Daniel Palmer
2025-12-28 19:29 ` Kuan-Wei Chiu
0 siblings, 1 reply; 19+ messages in thread
From: Daniel Palmer @ 2025-12-28 1:28 UTC (permalink / raw)
To: Kuan-Wei Chiu; +Cc: alison.wang, angelo, trini, me, jserv, eleanor15x, u-boot
Hi Kuan-Wei,
On Sat, 27 Dec 2025 at 02:54, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> diff --git a/arch/m68k/cpu/m680x0/cpu.c b/arch/m68k/cpu/m680x0/cpu.c
> new file mode 100644
> index 00000000000..15e0c30980a
> --- /dev/null
> +++ b/arch/m68k/cpu/m680x0/cpu.c
> +void m68k_virt_init_reserve(ulong base)
> +{
> + /* FIXME: usage of memset() here caused a hang on QEMU m68k virt. */
> + for (i = 0; i < sizeof(*gd_ptr); i++)
> + p[i] = 0;
Connecting GDB and single stepping to work out where it is going would
be helpful.
> +void relocate_code(ulong sp, struct global_data *new_gd, ulong relocaddr)
> +{
> + board_init_r(new_gd, relocaddr);
> +}
I have this working so at a later date we can copy/paste that code and
clean it up.
> +unsigned long timer_read_counter(void) { return 0; }
Since there is now a goldfish RTC driver upstream
(drivers/rtc/goldfish_rtc.c) we could take the timer part from my
version (https://github.com/fifteenhex/u-boot/blob/mc68000/drivers/rtc/goldfish_timer.c)
and supply a real timer to the board. Right now I think anything that
uses delays will get stuck constantly reading back 0?
> +void __udelay(unsigned long usec) {}
Or maybe delays just won't happen?
Cheers,
Daniel
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH v2 2/4] m68k: Add support for M68040 CPU
2025-12-28 1:28 ` Daniel Palmer
@ 2025-12-28 19:29 ` Kuan-Wei Chiu
2025-12-29 1:54 ` Daniel Palmer
0 siblings, 1 reply; 19+ messages in thread
From: Kuan-Wei Chiu @ 2025-12-28 19:29 UTC (permalink / raw)
To: Daniel Palmer; +Cc: alison.wang, angelo, trini, me, jserv, eleanor15x, u-boot
Hi Daniel,
On Sun, Dec 28, 2025 at 10:28:59AM +0900, Daniel Palmer wrote:
> Hi Kuan-Wei,
>
> On Sat, 27 Dec 2025 at 02:54, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> > diff --git a/arch/m68k/cpu/m680x0/cpu.c b/arch/m68k/cpu/m680x0/cpu.c
> > new file mode 100644
> > index 00000000000..15e0c30980a
> > --- /dev/null
> > +++ b/arch/m68k/cpu/m680x0/cpu.c
>
> > +void m68k_virt_init_reserve(ulong base)
> > +{
>
> > + /* FIXME: usage of memset() here caused a hang on QEMU m68k virt. */
> > + for (i = 0; i < sizeof(*gd_ptr); i++)
> > + p[i] = 0;
>
> Connecting GDB and single stepping to work out where it is going would
> be helpful.
I did attempt to investigate this using gdb, but unfortunately, the
root cause remains elusive. memset itself appears to execute correctly,
successfully zeroing out the global data. However, using it seems to
trigger a side effect where initcall_run_f() returns (which should not
happen), leading to the hang.
>
> > +void relocate_code(ulong sp, struct global_data *new_gd, ulong relocaddr)
> > +{
> > + board_init_r(new_gd, relocaddr);
> > +}
>
> I have this working so at a later date we can copy/paste that code and
> clean it up.
That sounds great. :)
I look forward to integrating that in the future.
>
> > +unsigned long timer_read_counter(void) { return 0; }
>
> Since there is now a goldfish RTC driver upstream
> (drivers/rtc/goldfish_rtc.c) we could take the timer part from my
> version (https://github.com/fifteenhex/u-boot/blob/mc68000/drivers/rtc/goldfish_timer.c)
> and supply a real timer to the board. Right now I think anything that
> uses delays will get stuck constantly reading back 0?
My original plan was to focus on a minimal boot to shell support in
this series and add rtc/timer support later. However, if you prefer to
have them included in this series, I am fine with that.
Since the timer driver is authored by you, I assume I should add
Co-developed-by and Signed-off-by tags with your name to credit you
properly. I wanted to explicitly ask for your permission first.
Also, regarding the tags, would you prefer I send the integrated patch
to you privately for verification before posting v3, or is posting it
directly to the list fine?
>
> > +void __udelay(unsigned long usec) {}
>
> Or maybe delays just won't happen?
I confirmed that delays do not occur during the boot to shell sequence.
They would only be triggered if specific commands (like sleep 5) are
executed after booting to shell.
Regards,
Kuan-Wei
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH v2 2/4] m68k: Add support for M68040 CPU
2025-12-28 19:29 ` Kuan-Wei Chiu
@ 2025-12-29 1:54 ` Daniel Palmer
2025-12-29 13:27 ` Kuan-Wei Chiu
0 siblings, 1 reply; 19+ messages in thread
From: Daniel Palmer @ 2025-12-29 1:54 UTC (permalink / raw)
To: Kuan-Wei Chiu; +Cc: alison.wang, angelo, trini, me, jserv, eleanor15x, u-boot
Hi Kuan-Wei,
On Mon, 29 Dec 2025 at 04:29, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> > Connecting GDB and single stepping to work out where it is going would
> > be helpful.
>
> I did attempt to investigate this using gdb, but unfortunately, the
> root cause remains elusive. memset itself appears to execute correctly,
> successfully zeroing out the global data. However, using it seems to
> trigger a side effect where initcall_run_f() returns (which should not
> happen), leading to the hang.
Maybe a QEMU bug? If I get some time I will try to reproduce it.
> > Since there is now a goldfish RTC driver upstream
> > (drivers/rtc/goldfish_rtc.c) we could take the timer part from my
> > version (https://github.com/fifteenhex/u-boot/blob/mc68000/drivers/rtc/goldfish_timer.c)
> > and supply a real timer to the board. Right now I think anything that
> > uses delays will get stuck constantly reading back 0?
>
> My original plan was to focus on a minimal boot to shell support in
> this series and add rtc/timer support later. However, if you prefer to
> have them included in this series, I am fine with that.
I looked at adding the timer parts of my "goldfish rtc" driver to the
upstream one and it's not very clean.
So I have removed the unfinished RTC bits from my driver and moved the
whole thing to drivers/timers/.
That seems like a better way to go. I think having working delays etc
would be nice even for the initial support.
I guess if you send your initial stuff and someone asks "why is there
no timer?" you can tell them I'll send a driver for that in the next
series?
> Since the timer driver is authored by you, I assume I should add
> Co-developed-by and Signed-off-by tags with your name to credit you
> properly. I wanted to explicitly ask for your permission first.
If there is anything in my branch you find useful you have my
permission to just copy and paste without adding any tags etc.
Credit is nice but I don't really mind.
> Also, regarding the tags, would you prefer I send the integrated patch
> to you privately for verification before posting v3, or is posting it
> directly to the list fine?
Can you put the branch on github or something for me? If you send me
patches I'm going to have to import them to my local checkout to look
at so if you have a branch I can access that's less steps. :D
Cheers,
Daniel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2 2/4] m68k: Add support for M68040 CPU
2025-12-29 1:54 ` Daniel Palmer
@ 2025-12-29 13:27 ` Kuan-Wei Chiu
0 siblings, 0 replies; 19+ messages in thread
From: Kuan-Wei Chiu @ 2025-12-29 13:27 UTC (permalink / raw)
To: Daniel Palmer; +Cc: alison.wang, angelo, trini, me, jserv, eleanor15x, u-boot
Hi Daniel,
On Mon, Dec 29, 2025 at 10:54:45AM +0900, Daniel Palmer wrote:
> Hi Kuan-Wei,
>
> On Mon, 29 Dec 2025 at 04:29, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> > > Connecting GDB and single stepping to work out where it is going would
> > > be helpful.
> >
> > I did attempt to investigate this using gdb, but unfortunately, the
> > root cause remains elusive. memset itself appears to execute correctly,
> > successfully zeroing out the global data. However, using it seems to
> > trigger a side effect where initcall_run_f() returns (which should not
> > happen), leading to the hang.
>
> Maybe a QEMU bug? If I get some time I will try to reproduce it.
>
> > > Since there is now a goldfish RTC driver upstream
> > > (drivers/rtc/goldfish_rtc.c) we could take the timer part from my
> > > version (https://github.com/fifteenhex/u-boot/blob/mc68000/drivers/rtc/goldfish_timer.c)
> > > and supply a real timer to the board. Right now I think anything that
> > > uses delays will get stuck constantly reading back 0?
> >
> > My original plan was to focus on a minimal boot to shell support in
> > this series and add rtc/timer support later. However, if you prefer to
> > have them included in this series, I am fine with that.
>
> I looked at adding the timer parts of my "goldfish rtc" driver to the
> upstream one and it's not very clean.
> So I have removed the unfinished RTC bits from my driver and moved the
> whole thing to drivers/timers/.
> That seems like a better way to go. I think having working delays etc
> would be nice even for the initial support.
> I guess if you send your initial stuff and someone asks "why is there
> no timer?" you can tell them I'll send a driver for that in the next
> series?
Sure, I will add rtc and timer support in the next version. Thanks!
>
> > Since the timer driver is authored by you, I assume I should add
> > Co-developed-by and Signed-off-by tags with your name to credit you
> > properly. I wanted to explicitly ask for your permission first.
>
> If there is anything in my branch you find useful you have my
> permission to just copy and paste without adding any tags etc.
> Credit is nice but I don't really mind.
Got it. Thanks.
>
> > Also, regarding the tags, would you prefer I send the integrated patch
> > to you privately for verification before posting v3, or is posting it
> > directly to the list fine?
>
> Can you put the branch on github or something for me? If you send me
> patches I'm going to have to import them to my local checkout to look
> at so if you have a branch I can access that's less steps. :D
Sure, I will push the series to github and share the link.
Regards,
Kuan-Wei
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v2 3/4] board: Add QEMU m68k virt board support
2025-12-26 17:53 [PATCH v2 0/4] m68k: Add support for QEMU virt machine Kuan-Wei Chiu
2025-12-26 17:53 ` [PATCH v2 1/4] serial: Add Goldfish TTY driver Kuan-Wei Chiu
2025-12-26 17:53 ` [PATCH v2 2/4] m68k: Add support for M68040 CPU Kuan-Wei Chiu
@ 2025-12-26 17:53 ` Kuan-Wei Chiu
2025-12-28 1:16 ` Daniel Palmer
2025-12-26 17:54 ` [PATCH v2 4/4] CI: Add test jobs for QEMU m68k virt machine Kuan-Wei Chiu
3 siblings, 1 reply; 19+ messages in thread
From: Kuan-Wei Chiu @ 2025-12-26 17:53 UTC (permalink / raw)
To: alison.wang, angelo
Cc: trini, me, daniel, jserv, eleanor15x, u-boot, Kuan-Wei Chiu
Add support for the QEMU 'virt' machine on the m68k architecture. This
board emulates a generic machine based on the Motorola 68040 CPU
equipped with Goldfish virtual peripherals.
Introduce the necessary board configuration and initialization
infrastructure. The implementation includes logic to parse the QEMU
bootinfo interface, enabling dynamic detection of system RAM size to
adapt to the virtual machine's configuration.
Enable the Goldfish TTY driver to provide a serial console, which
facilitates interaction when running QEMU with the -nographic option.
Additionally, include comprehensive documentation covering build
instructions and usage examples to guide users in deploying U-Boot
within the virtualization environment.
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
---
Changes in v2:
- Update SPDX license identifier to GPL-2.0-or-later.
- Sort header inclusions alphabetically.
- Fix tabs vs spaces in MAINTAINERS.
- Add qemu-m68k entry to doc/board/emulation/index.rst.
- Regenerate defconfig using make savedefconfig.
arch/m68k/Kconfig | 8 +++
board/emulation/qemu-m68k/Kconfig | 12 ++++
board/emulation/qemu-m68k/MAINTAINERS | 8 +++
board/emulation/qemu-m68k/Makefile | 5 ++
board/emulation/qemu-m68k/qemu-m68k.c | 84 +++++++++++++++++++++++++++
configs/qemu-m68k_defconfig | 12 ++++
doc/board/emulation/index.rst | 1 +
doc/board/emulation/qemu-m68k.rst | 38 ++++++++++++
include/configs/qemu-m68k.h | 18 ++++++
9 files changed, 186 insertions(+)
create mode 100644 board/emulation/qemu-m68k/Kconfig
create mode 100644 board/emulation/qemu-m68k/MAINTAINERS
create mode 100644 board/emulation/qemu-m68k/Makefile
create mode 100644 board/emulation/qemu-m68k/qemu-m68k.c
create mode 100644 configs/qemu-m68k_defconfig
create mode 100644 doc/board/emulation/qemu-m68k.rst
create mode 100644 include/configs/qemu-m68k.h
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index de7c673c376..605ae5ec20c 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -183,6 +183,13 @@ config TARGET_STMARK2
select CF_DSPI
select M54418
+config TARGET_QEMU_M68K
+ bool "Support QEMU m68k virt"
+ select M68040
+ help
+ This target supports the QEMU m68k virtual machine (-M virt).
+ It simulates a Motorola 68040 CPU with Goldfish peripherals.
+
endchoice
config SYS_CPU
@@ -208,6 +215,7 @@ source "board/freescale/m5329evb/Kconfig"
source "board/freescale/m5373evb/Kconfig"
source "board/sysam/amcore/Kconfig"
source "board/sysam/stmark2/Kconfig"
+source "board/emulation/qemu-m68k/Kconfig"
config M68K_QEMU
bool "Build with workarounds for incomplete QEMU emulation"
diff --git a/board/emulation/qemu-m68k/Kconfig b/board/emulation/qemu-m68k/Kconfig
new file mode 100644
index 00000000000..aae6dfe400f
--- /dev/null
+++ b/board/emulation/qemu-m68k/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_QEMU_M68K
+
+config SYS_BOARD
+ default "qemu-m68k"
+
+config SYS_VENDOR
+ default "emulation"
+
+config SYS_CONFIG_NAME
+ default "qemu-m68k"
+
+endif
diff --git a/board/emulation/qemu-m68k/MAINTAINERS b/board/emulation/qemu-m68k/MAINTAINERS
new file mode 100644
index 00000000000..90414c58465
--- /dev/null
+++ b/board/emulation/qemu-m68k/MAINTAINERS
@@ -0,0 +1,8 @@
+QEMU M68K VIRT BOARD
+M: Kuan-Wei Chiu <visitorckw@gmail.com>
+S: Maintained
+F: board/emulation/qemu-m68k/
+F: board/emulation/common/
+F: include/configs/qemu-m68k.h
+F: configs/qemu-m68k_defconfig
+F: doc/board/emulation/qemu-m68k.rst
diff --git a/board/emulation/qemu-m68k/Makefile b/board/emulation/qemu-m68k/Makefile
new file mode 100644
index 00000000000..5cb2886ff5a
--- /dev/null
+++ b/board/emulation/qemu-m68k/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2025, Kuan-Wei Chiu <visitorckw@gmail.com>
+
+obj-y += qemu-m68k.o
diff --git a/board/emulation/qemu-m68k/qemu-m68k.c b/board/emulation/qemu-m68k/qemu-m68k.c
new file mode 100644
index 00000000000..89e66050bb9
--- /dev/null
+++ b/board/emulation/qemu-m68k/qemu-m68k.c
@@ -0,0 +1,84 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2025, Kuan-Wei Chiu <visitorckw@gmail.com>
+ */
+
+#include <asm-generic/sections.h>
+#include <asm/bootinfo.h>
+#include <asm/global_data.h>
+#include <asm/io.h>
+#include <config.h>
+#include <dm/platdata.h>
+#include <goldfish_tty.h>
+#include <init.h>
+#include <linux/errno.h>
+#include <serial.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* QEMU Virt Machine Hardware Map */
+#define VIRT_GF_TTY_MMIO_BASE 0xff008000
+#define VIRT_CTRL_MMIO_BASE 0xff009000
+#define VIRT_CTRL_RESET 0x01
+
+int board_early_init_f(void)
+{
+ return 0;
+}
+
+int checkboard(void)
+{
+ puts("Board: QEMU m68k virt\n");
+ return 0;
+}
+
+int dram_init(void)
+{
+ struct bi_record *record;
+ ulong addr;
+
+ /* Default: 16MB */
+ gd->ram_size = 0x01000000;
+
+ /* QEMU places bootinfo after _end, aligned to 2 bytes */
+ addr = (ulong)&_end;
+ if (addr & 1)
+ addr++;
+
+ record = (struct bi_record *)addr;
+
+ if (record->tag != BI_MACHTYPE)
+ return 0;
+
+ while (record->tag != BI_LAST) {
+ if (record->tag == BI_MEMCHUNK) {
+ gd->ram_size = record->data[1];
+ break;
+ }
+ record = (struct bi_record *)((ulong)record + record->size);
+ }
+
+ return 0;
+}
+
+void reset_cpu(unsigned long addr)
+{
+ writel(VIRT_CTRL_RESET, VIRT_CTRL_MMIO_BASE);
+ while (1)
+ ;
+}
+
+int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
+{
+ reset_cpu(0);
+ return 0;
+}
+
+static const struct goldfish_tty_plat serial_plat = {
+ .base = (void __iomem *)VIRT_GF_TTY_MMIO_BASE,
+};
+
+U_BOOT_DRVINFO(goldfish_serial) = {
+ .name = "serial_goldfish",
+ .plat = &serial_plat,
+};
diff --git a/configs/qemu-m68k_defconfig b/configs/qemu-m68k_defconfig
new file mode 100644
index 00000000000..db6c9b1c771
--- /dev/null
+++ b/configs/qemu-m68k_defconfig
@@ -0,0 +1,12 @@
+CONFIG_M68K=y
+CONFIG_TEXT_BASE=0x00000000
+CONFIG_SYS_MALLOC_LEN=0x20000
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SYS_MONITOR_LEN=262144
+CONFIG_SYS_BOOTM_LEN=0x1000000
+CONFIG_SYS_LOAD_ADDR=0x00000000
+CONFIG_TARGET_QEMU_M68K=y
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_DM_SERIAL=y
+CONFIG_SERIAL_GOLDFISH=y
diff --git a/doc/board/emulation/index.rst b/doc/board/emulation/index.rst
index f8908166276..4f7c812d493 100644
--- a/doc/board/emulation/index.rst
+++ b/doc/board/emulation/index.rst
@@ -15,6 +15,7 @@ Emulation
qemu-sbsa
qemu-x86
qemu-xtensa
+ qemu-m68k
Also see
diff --git a/doc/board/emulation/qemu-m68k.rst b/doc/board/emulation/qemu-m68k.rst
new file mode 100644
index 00000000000..36e51e8107f
--- /dev/null
+++ b/doc/board/emulation/qemu-m68k.rst
@@ -0,0 +1,38 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+.. Copyright (C) 2025, Kuan-Wei Chiu <visitorckw@gmail.com>
+
+QEMU m68k
+=========
+
+QEMU for m68k supports a special 'virt' machine designed for emulation and
+virtualization purposes. This document describes how to run U-Boot under it.
+
+The QEMU virt machine models a generic m68k virtual machine with Goldfish
+interfaces. It supports the Motorola 68040 CPU architecture.
+
+Building U-Boot
+---------------
+Set the CROSS_COMPILE environment variable to your m68k toolchain, and run:
+
+.. code-block:: bash
+
+ export CROSS_COMPILE=m68k-linux-gnu-
+ make qemu-m68k_defconfig
+ make
+
+Running U-Boot
+--------------
+The minimal QEMU command line to get U-Boot up and running is:
+
+.. code-block:: bash
+
+ qemu-system-m68k -M virt -cpu m68040 -nographic -kernel u-boot
+
+Note that the `-nographic` option is used to redirect the console to stdio,
+which connects to the emulated Goldfish TTY device.
+
+Hardware Support
+----------------
+The following QEMU virt peripherals are supported in U-Boot:
+
+* Goldfish TTY (Serial Console)
diff --git a/include/configs/qemu-m68k.h b/include/configs/qemu-m68k.h
new file mode 100644
index 00000000000..1d8aa92fe80
--- /dev/null
+++ b/include/configs/qemu-m68k.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2025, Kuan-Wei Chiu <visitorckw@gmail.com>
+ */
+
+#ifndef __QEMU_M68K_H
+#define __QEMU_M68K_H
+
+/* Memory Configuration */
+#define CFG_SYS_SDRAM_BASE 0x00000000
+
+/*
+ * Initial Stack Pointer:
+ * Place the stack at 4MB offset to avoid overwriting U-Boot code/data.
+ */
+#define CFG_SYS_INIT_SP_ADDR (CFG_SYS_SDRAM_BASE + 0x400000)
+
+#endif /* __QEMU_M68K_H */
--
2.52.0.358.g0dd7633a29-goog
^ permalink raw reply related [flat|nested] 19+ messages in thread* Re: [PATCH v2 3/4] board: Add QEMU m68k virt board support
2025-12-26 17:53 ` [PATCH v2 3/4] board: Add QEMU m68k virt board support Kuan-Wei Chiu
@ 2025-12-28 1:16 ` Daniel Palmer
2025-12-28 19:13 ` Kuan-Wei Chiu
0 siblings, 1 reply; 19+ messages in thread
From: Daniel Palmer @ 2025-12-28 1:16 UTC (permalink / raw)
To: Kuan-Wei Chiu; +Cc: alison.wang, angelo, trini, me, jserv, eleanor15x, u-boot
Hi Kuan-Wei,
On Sat, 27 Dec 2025 at 02:54, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> diff --git a/board/emulation/qemu-m68k/qemu-m68k.c b/board/emulation/qemu-m68k/qemu-m68k.c
> +int dram_init(void)
> +{
> + /* QEMU places bootinfo after _end, aligned to 2 bytes */
> + addr = (ulong)&_end;
> + if (addr & 1)
> + addr++;
Maybe ALIGN() or round_up() could be used here instead of manually coding it?
> + record = (struct bi_record *)addr;
> +
> + if (record->tag != BI_MACHTYPE)
> + return 0;
> +
> + while (record->tag != BI_LAST) {
> + if (record->tag == BI_MEMCHUNK) {
> + gd->ram_size = record->data[1];
> + break;
> + }
> + record = (struct bi_record *)((ulong)record + record->size);
> + }
One thing I found when I did the bootinfo parsing in my version is if
I corrupted (during relocation etc) the bootinfo this type of loop
would often get stuck forever.
I'm not sure what the technical limit of the number of bootinfo
entries is but bounding this to something reasonable feels like a good
idea.
Cheers,
Daniel
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH v2 3/4] board: Add QEMU m68k virt board support
2025-12-28 1:16 ` Daniel Palmer
@ 2025-12-28 19:13 ` Kuan-Wei Chiu
2025-12-29 1:42 ` Daniel Palmer
0 siblings, 1 reply; 19+ messages in thread
From: Kuan-Wei Chiu @ 2025-12-28 19:13 UTC (permalink / raw)
To: Daniel Palmer; +Cc: alison.wang, angelo, trini, me, jserv, eleanor15x, u-boot
Hi Daniel,
On Sun, Dec 28, 2025 at 10:16:01AM +0900, Daniel Palmer wrote:
> Hi Kuan-Wei,
>
> On Sat, 27 Dec 2025 at 02:54, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> > diff --git a/board/emulation/qemu-m68k/qemu-m68k.c b/board/emulation/qemu-m68k/qemu-m68k.c
>
> > +int dram_init(void)
> > +{
>
> > + /* QEMU places bootinfo after _end, aligned to 2 bytes */
> > + addr = (ulong)&_end;
> > + if (addr & 1)
> > + addr++;
>
> Maybe ALIGN() or round_up() could be used here instead of manually coding it?
Ack. Using ALIGN() is indeed cleaner.
I will update this in the next version.
>
> > + record = (struct bi_record *)addr;
> > +
> > + if (record->tag != BI_MACHTYPE)
> > + return 0;
> > +
> > + while (record->tag != BI_LAST) {
> > + if (record->tag == BI_MEMCHUNK) {
> > + gd->ram_size = record->data[1];
> > + break;
> > + }
> > + record = (struct bi_record *)((ulong)record + record->size);
> > + }
>
> One thing I found when I did the bootinfo parsing in my version is if
> I corrupted (during relocation etc) the bootinfo this type of loop
> would often get stuck forever.
> I'm not sure what the technical limit of the number of bootinfo
> entries is but bounding this to something reasonable feels like a good
> idea.
In that scenario, I assume the correct error handling would be to add a
loop limit and trigger a panic() if exceeded?
Regards,
Kuan-Wei
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH v2 3/4] board: Add QEMU m68k virt board support
2025-12-28 19:13 ` Kuan-Wei Chiu
@ 2025-12-29 1:42 ` Daniel Palmer
2025-12-29 13:44 ` Kuan-Wei Chiu
0 siblings, 1 reply; 19+ messages in thread
From: Daniel Palmer @ 2025-12-29 1:42 UTC (permalink / raw)
To: Kuan-Wei Chiu; +Cc: alison.wang, angelo, trini, me, jserv, eleanor15x, u-boot
Hi Kuan-Wei,
On Mon, 29 Dec 2025 at 04:13, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> >
> > One thing I found when I did the bootinfo parsing in my version is if
> > I corrupted (during relocation etc) the bootinfo this type of loop
> > would often get stuck forever.
> > I'm not sure what the technical limit of the number of bootinfo
> > entries is but bounding this to something reasonable feels like a good
> > idea.
>
> In that scenario, I assume the correct error handling would be to add a
> loop limit and trigger a panic() if exceeded?
Yeah I think so, if you didn't find the last bootinfo entry within
some reasonable bounds everything is probably broken and you shouldn't
continue.
I think for most real machines (Amiga etc) there aren't many entries
but for the virt machine maybe there is an entry per virtio mmio
device so there might actually be a lot of them there.
Cheers,
Daniel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2 3/4] board: Add QEMU m68k virt board support
2025-12-29 1:42 ` Daniel Palmer
@ 2025-12-29 13:44 ` Kuan-Wei Chiu
2025-12-31 3:20 ` Daniel Palmer
0 siblings, 1 reply; 19+ messages in thread
From: Kuan-Wei Chiu @ 2025-12-29 13:44 UTC (permalink / raw)
To: Daniel Palmer; +Cc: alison.wang, angelo, trini, me, jserv, eleanor15x, u-boot
Hi Daniel,
On Mon, Dec 29, 2025 at 10:42:54AM +0900, Daniel Palmer wrote:
> Hi Kuan-Wei,
>
> On Mon, 29 Dec 2025 at 04:13, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> > >
> > > One thing I found when I did the bootinfo parsing in my version is if
> > > I corrupted (during relocation etc) the bootinfo this type of loop
> > > would often get stuck forever.
> > > I'm not sure what the technical limit of the number of bootinfo
> > > entries is but bounding this to something reasonable feels like a good
> > > idea.
> >
> > In that scenario, I assume the correct error handling would be to add a
> > loop limit and trigger a panic() if exceeded?
>
> Yeah I think so, if you didn't find the last bootinfo entry within
> some reasonable bounds everything is probably broken and you shouldn't
> continue.
> I think for most real machines (Amiga etc) there aren't many entries
> but for the virt machine maybe there is an entry per virtio mmio
> device so there might actually be a lot of them there.
So the problem becomes determining a reasonable limit.
I think we can safely assume the bootinfo buffer won't exceed a 4KB
page size. Since the minimum record size is 4 bytes (tag + size),
setting the maximum records to 4096 / 4 =1024 should be a safe
assumption?
Regards,
Kuan-Wei
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2 3/4] board: Add QEMU m68k virt board support
2025-12-29 13:44 ` Kuan-Wei Chiu
@ 2025-12-31 3:20 ` Daniel Palmer
0 siblings, 0 replies; 19+ messages in thread
From: Daniel Palmer @ 2025-12-31 3:20 UTC (permalink / raw)
To: Kuan-Wei Chiu; +Cc: alison.wang, angelo, trini, me, jserv, eleanor15x, u-boot
Hi Kuan-Wei,
On Mon, 29 Dec 2025 at 22:44, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> > Yeah I think so, if you didn't find the last bootinfo entry within
> > some reasonable bounds everything is probably broken and you shouldn't
> > continue.
> > I think for most real machines (Amiga etc) there aren't many entries
> > but for the virt machine maybe there is an entry per virtio mmio
> > device so there might actually be a lot of them there.
>
> So the problem becomes determining a reasonable limit.
>
> I think we can safely assume the bootinfo buffer won't exceed a 4KB
> page size. Since the minimum record size is 4 bytes (tag + size),
> setting the maximum records to 4096 / 4 =1024 should be a safe
> assumption?
All of the bootinfo being on a single page makes sense to me[0] and if
an error is printed if the last entry is not found within that it'll
be easy to work out that there is more and adjust the limit.
That is a lot better than the bootinfo being corrupted and parsing
random memory until we hit something that looks like the last record.
;)
Cheers,
Daniel
0 - I feel like I saw that assumption somewhere but can't remember
where, maybe in the EMILE mac bootloader..
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v2 4/4] CI: Add test jobs for QEMU m68k virt machine
2025-12-26 17:53 [PATCH v2 0/4] m68k: Add support for QEMU virt machine Kuan-Wei Chiu
` (2 preceding siblings ...)
2025-12-26 17:53 ` [PATCH v2 3/4] board: Add QEMU m68k virt board support Kuan-Wei Chiu
@ 2025-12-26 17:54 ` Kuan-Wei Chiu
2025-12-26 18:09 ` Tom Rini
3 siblings, 1 reply; 19+ messages in thread
From: Kuan-Wei Chiu @ 2025-12-26 17:54 UTC (permalink / raw)
To: alison.wang, angelo
Cc: trini, me, daniel, jserv, eleanor15x, u-boot, Kuan-Wei Chiu
Enable CI testing for the newly introduced QEMU m68k 'virt' board on
both GitLab CI and Azure Pipelines. This ensures the new M68040
architecture support is built and booted correctly in the emulated
environment.
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
---
Changes in v2:
- New patch to add CI testing jobs for gitlab and azure pipelines.
Note: This patch depends on a corresponding patch to the
u-boot-test-hooks repository to provide the necessary QEMU
configuration: "travis-ci: Add config for QEMU m68k virt machine"
The gitlab CI job has been verified locally using gitlab-ci-local tool
with a passing result. Azure Pipelines has not been verified.
.azure-pipelines.yml | 4 ++++
.gitlab-ci.yml | 7 +++++++
2 files changed, 11 insertions(+)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index e4695f1c55b..41bba8ed0f1 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -518,6 +518,10 @@ stages:
TEST_PY_ID: "--id qemu"
TEST_PY_TEST_SPEC: "not sleep and not efi"
OVERRIDE: "-a CONFIG_M68K_QEMU=y -a ~CONFIG_MCFTMR"
+ qemu_m68k_virt:
+ TEST_PY_BD: "qemu-m68k"
+ TEST_PY_ID: "--id qemu"
+ TEST_PY_TEST_SPEC: "not sleep"
qemu_malta:
TEST_PY_BD: "malta"
TEST_PY_ID: "--id qemu"
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index e7234e003ea..08dbffc74bd 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -408,6 +408,13 @@ qemu_m68k test.py:
OVERRIDE: "-a CONFIG_M68K_QEMU=y -a ~CONFIG_MCFTMR"
<<: *buildman_and_testpy_dfn
+qemu_m68k_virt test.py:
+ variables:
+ TEST_PY_BD: "qemu-m68k"
+ TEST_PY_ID: "--id qemu"
+ TEST_PY_TEST_SPEC: "not sleep"
+ <<: *buildman_and_testpy_dfn
+
qemu_malta test.py:
variables:
TEST_PY_BD: "malta"
--
2.52.0.358.g0dd7633a29-goog
^ permalink raw reply related [flat|nested] 19+ messages in thread* Re: [PATCH v2 4/4] CI: Add test jobs for QEMU m68k virt machine
2025-12-26 17:54 ` [PATCH v2 4/4] CI: Add test jobs for QEMU m68k virt machine Kuan-Wei Chiu
@ 2025-12-26 18:09 ` Tom Rini
2025-12-26 18:57 ` Kuan-Wei Chiu
0 siblings, 1 reply; 19+ messages in thread
From: Tom Rini @ 2025-12-26 18:09 UTC (permalink / raw)
To: Kuan-Wei Chiu; +Cc: alison.wang, angelo, me, daniel, jserv, eleanor15x, u-boot
[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]
On Fri, Dec 26, 2025 at 05:54:00PM +0000, Kuan-Wei Chiu wrote:
> Enable CI testing for the newly introduced QEMU m68k 'virt' board on
> both GitLab CI and Azure Pipelines. This ensures the new M68040
> architecture support is built and booted correctly in the emulated
> environment.
>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> ---
> Changes in v2:
> - New patch to add CI testing jobs for gitlab and azure pipelines.
>
> Note: This patch depends on a corresponding patch to the
> u-boot-test-hooks repository to provide the necessary QEMU
> configuration: "travis-ci: Add config for QEMU m68k virt machine"
>
> The gitlab CI job has been verified locally using gitlab-ci-local tool
> with a passing result. Azure Pipelines has not been verified.
>
> .azure-pipelines.yml | 4 ++++
> .gitlab-ci.yml | 7 +++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> index e4695f1c55b..41bba8ed0f1 100644
> --- a/.azure-pipelines.yml
> +++ b/.azure-pipelines.yml
> @@ -518,6 +518,10 @@ stages:
> TEST_PY_ID: "--id qemu"
> TEST_PY_TEST_SPEC: "not sleep and not efi"
> OVERRIDE: "-a CONFIG_M68K_QEMU=y -a ~CONFIG_MCFTMR"
> + qemu_m68k_virt:
> + TEST_PY_BD: "qemu-m68k"
> + TEST_PY_ID: "--id qemu"
I see why you set TEST_PY_ID but that's only used in this manner for
platforms which can be real or virtualized, for the qemu targets we just
omit that (and then name the u-boot-test-hooks files to be "_na" or can
just omit that part. Thanks for adding this!
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2 4/4] CI: Add test jobs for QEMU m68k virt machine
2025-12-26 18:09 ` Tom Rini
@ 2025-12-26 18:57 ` Kuan-Wei Chiu
2025-12-26 18:59 ` Tom Rini
0 siblings, 1 reply; 19+ messages in thread
From: Kuan-Wei Chiu @ 2025-12-26 18:57 UTC (permalink / raw)
To: Tom Rini; +Cc: alison.wang, angelo, me, daniel, jserv, eleanor15x, u-boot
Hi Tom,
On Fri, Dec 26, 2025 at 12:09:04PM -0600, Tom Rini wrote:
> On Fri, Dec 26, 2025 at 05:54:00PM +0000, Kuan-Wei Chiu wrote:
> > Enable CI testing for the newly introduced QEMU m68k 'virt' board on
> > both GitLab CI and Azure Pipelines. This ensures the new M68040
> > architecture support is built and booted correctly in the emulated
> > environment.
> >
> > Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> > ---
> > Changes in v2:
> > - New patch to add CI testing jobs for gitlab and azure pipelines.
> >
> > Note: This patch depends on a corresponding patch to the
> > u-boot-test-hooks repository to provide the necessary QEMU
> > configuration: "travis-ci: Add config for QEMU m68k virt machine"
> >
> > The gitlab CI job has been verified locally using gitlab-ci-local tool
> > with a passing result. Azure Pipelines has not been verified.
> >
> > .azure-pipelines.yml | 4 ++++
> > .gitlab-ci.yml | 7 +++++++
> > 2 files changed, 11 insertions(+)
> >
> > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > index e4695f1c55b..41bba8ed0f1 100644
> > --- a/.azure-pipelines.yml
> > +++ b/.azure-pipelines.yml
> > @@ -518,6 +518,10 @@ stages:
> > TEST_PY_ID: "--id qemu"
> > TEST_PY_TEST_SPEC: "not sleep and not efi"
> > OVERRIDE: "-a CONFIG_M68K_QEMU=y -a ~CONFIG_MCFTMR"
> > + qemu_m68k_virt:
> > + TEST_PY_BD: "qemu-m68k"
> > + TEST_PY_ID: "--id qemu"
>
> I see why you set TEST_PY_ID but that's only used in this manner for
> platforms which can be real or virtualized, for the qemu targets we just
> omit that (and then name the u-boot-test-hooks files to be "_na" or can
> just omit that part. Thanks for adding this!
Thanks for the quick feedback!
I'll fix the TEST_PY_ID usage.
Is there a preferred waiting period (like the 24 hr rule in Linux
netdev) before I send v3? I can send the fix immediately, but I want to
make sure I'm following the proper etiquette, especially during the
Christmas holidays.
Regards,
Kuan-Wei
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2 4/4] CI: Add test jobs for QEMU m68k virt machine
2025-12-26 18:57 ` Kuan-Wei Chiu
@ 2025-12-26 18:59 ` Tom Rini
0 siblings, 0 replies; 19+ messages in thread
From: Tom Rini @ 2025-12-26 18:59 UTC (permalink / raw)
To: Kuan-Wei Chiu; +Cc: alison.wang, angelo, me, daniel, jserv, eleanor15x, u-boot
[-- Attachment #1: Type: text/plain, Size: 2619 bytes --]
On Sat, Dec 27, 2025 at 02:57:11AM +0800, Kuan-Wei Chiu wrote:
> Hi Tom,
>
> On Fri, Dec 26, 2025 at 12:09:04PM -0600, Tom Rini wrote:
> > On Fri, Dec 26, 2025 at 05:54:00PM +0000, Kuan-Wei Chiu wrote:
> > > Enable CI testing for the newly introduced QEMU m68k 'virt' board on
> > > both GitLab CI and Azure Pipelines. This ensures the new M68040
> > > architecture support is built and booted correctly in the emulated
> > > environment.
> > >
> > > Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> > > ---
> > > Changes in v2:
> > > - New patch to add CI testing jobs for gitlab and azure pipelines.
> > >
> > > Note: This patch depends on a corresponding patch to the
> > > u-boot-test-hooks repository to provide the necessary QEMU
> > > configuration: "travis-ci: Add config for QEMU m68k virt machine"
> > >
> > > The gitlab CI job has been verified locally using gitlab-ci-local tool
> > > with a passing result. Azure Pipelines has not been verified.
> > >
> > > .azure-pipelines.yml | 4 ++++
> > > .gitlab-ci.yml | 7 +++++++
> > > 2 files changed, 11 insertions(+)
> > >
> > > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > > index e4695f1c55b..41bba8ed0f1 100644
> > > --- a/.azure-pipelines.yml
> > > +++ b/.azure-pipelines.yml
> > > @@ -518,6 +518,10 @@ stages:
> > > TEST_PY_ID: "--id qemu"
> > > TEST_PY_TEST_SPEC: "not sleep and not efi"
> > > OVERRIDE: "-a CONFIG_M68K_QEMU=y -a ~CONFIG_MCFTMR"
> > > + qemu_m68k_virt:
> > > + TEST_PY_BD: "qemu-m68k"
> > > + TEST_PY_ID: "--id qemu"
> >
> > I see why you set TEST_PY_ID but that's only used in this manner for
> > platforms which can be real or virtualized, for the qemu targets we just
> > omit that (and then name the u-boot-test-hooks files to be "_na" or can
> > just omit that part. Thanks for adding this!
>
> Thanks for the quick feedback!
> I'll fix the TEST_PY_ID usage.
>
> Is there a preferred waiting period (like the 24 hr rule in Linux
> netdev) before I send v3? I can send the fix immediately, but I want to
> make sure I'm following the proper etiquette, especially during the
> Christmas holidays.
We don't have a specific defined waiting period, but since this isn't
a critical fix, yes, you can wait a few days even for more feedback
(since I recall you're collaborating with others that've been doing m68k
work on their own) before posting v3.
Ideally, this will get in v2026.04, which means it should be done and
merge-ready by end of January, so, plenty of time.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread