Re: [PATCH v2 4/4] CI: Add test jobs for QEMU m68k virt machine

Tom Rini
2025-12-26T18:59:33Z

[-- 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 --]