Re: [OE-core] [PATCH v6 0/7] Add barebox bootloader support (and testing)

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2024-09-19 at 11:47 +0200, Enrico Jörns wrote:
> Am Mittwoch, dem 18.09.2024 um 22:37 +0100 schrieb Richard Purdie:
> > On Wed, 2024-09-18 at 13:45 +0200, Enrico Jörns wrote:
> > > Am Mittwoch, dem 18.09.2024 um 12:21 +0100 schrieb Richard Purdie:
> > > > On Wed, 2024-09-18 at 12:39 +0200, Enrico Jörns wrote:
> > > > > Hi Richard,
> > > > > 
> > > > > Am Mittwoch, dem 18.09.2024 um 11:11 +0100 schrieb Richard
> > > > > Purdie:
> > > > > > On Thu, 2024-09-12 at 11:18 +0200, Enrico Jörns via
> > > > > > lists.openembedded.org wrote:
> > > > > > > This adds support for the barebox bootloader (and tools) to
> > > > > > > oe-
> > > > > > > core.
> > > > > > > 
> > > > > > > In order to have proper testing, this extends oe-selftest to
> > > > > > > allow
> > > > > > > basic testing of bootloaders. While at it, cover both u-boot
> > > > > > > and
> > > > > > > barebox.
> > > > > > > 
> > > > > > > v6:
> > > > > > > * replace barebox.inc by barebox.bbclass (move content of
> > > > > > >   barebox-common.inc into .bbclass and .bb files)
> > > > > > > * support for UNPACKDIR
> > > > > > > 
> > > > > > > Enrico Jorns (5):
> > > > > > >   barebox: set default BAREBOX_CONFIG for qemu machines
> > > > > > >   oeqa/utils/qemurunner: support ignoring vt100 escape
> > > > > > > sequences
> > > > > > >   oeqa: support passing custom boot patterns to runqemu
> > > > > > >   oeqa/selftest/cases: add basic u-boot test
> > > > > > >   oeqa/selftest/cases: add basic barebox tests
> > > > > > > 
> > > > > > > Marco Felsch (2):
> > > > > > >   barebox: add initial support
> > > > > > >   barebox-tools: add initial barebox tools support
> > > > > > 
> > > > > > We had some testing capacity so I ran this through automated
> > > > > > testing.
> > > > > > The one issue that showed up so far was:
> > > > > > 
> > > > > > https://valkyrie.yoctoproject.org/#/builders/29/builds/174/steps/13/logs/warnings
> > > > > > 
> > > > > > which is at least easily fixed! The rest of the build is still
> > > > > > going.
> > > > > 
> > > > > thanks for the test run and the first result.
> > > > > 
> > > > > Indeed, looks easily fixable 😉
> > > > > Is it worth a v7 or should I wait for other results to show up?
> > > > 
> > > > Most of the tests have run and there were other issues in the build
> > > > but
> > > > there was one other issue I noticed:
> > > > 
> > > > https://valkyrie.yoctoproject.org/#/builders/54/builds/149/steps/14/logs/stdio
> > > > 
> > > > which is a missing maintainers entry. Probably worth a v7 with
> > > > those
> > > > two things fixed.
> > > 
> > > The test output says
> > > 
> > > > Unable to find recipes for the following entries in
> > > > maintainers.inc:
> > > > barebox
> > > 
> > > Could you give me a hint what that means? The barebox_2024.08.0.bb
> > > and the change in maintainers.inc
> > > are in the same commit. So I am unsure why it does not find the
> > > recipe.
> > 
> > It means the recipe is being skipped in the context of the QA test.
> > This means there is a maintainers entry but the test can't see any
> > recipe to match against it due to the skip.
> 
> Thanks. I was not sure if the recipes are just evaluated and skipped based on normal bitbake parsing
> or if there is a special mechanism that just looks for .bb files.
> 
> > The test is there to ensure when we delete recipes, we don't have stale
> > entries in the file.
> > 
> > Can we provide a config that makes sense for qemux86-64?
> 
> The reason it is skipped from default parsing is
> 
>   PREFERRED_PROVIDER_virtual/bootloader = "u-boot"
> 
> I put in meta/conf/machine/qemux86-64.conf since we have two competing providers of
> virtaul/bootloader now (and that's what the mechanism is actually made for I guess 😉).
> 
> Not sure if there is a way to remove the provider for just that check?
> 
> Or should I add it to the exception list in distrodata.py like its done for similar other recipes
> that have competing providers (e.g. musl, newlib for virtual/libc; linux-yocto, linux-dummy for
> virtual/kernel)?.

I think it will just have to go into the exception list. We really need
to find a better way to do this but you're right, that is how we're
doing it for the other cases.

Cheers,

Richard