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 <[email protected]> > > > --- > > > 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
signature.asc
Description: PGP signature
