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 barebox and u-boot.

v2:
* set myself as maintainer in maintainers.inc
* move doc from documentation.conf to recipe
* update to barebox v2023.03 (including fixes for musl, etc.)
* set standard configs for qemu machines to allow building them
* add better efi dir support in barebox recipe
* enable testing bootloaders in oeqa
* add test cases for barebox (and u-boot)

Enrico Jorns (7):
barebox: set default BAREBOX_CONFIG for qemu machines
oeqa/utils/qemurunner: support ignoring vt100 escape sequences
oeqa/utils/qemurunner: simplify output parsing and make
crlf-compatible
oeqa/utils/commands: document runqemu context manager
oeqa: support passing custom boot patterns to runqemu
oeqa/selftest/cases: add barebox tests
oeqa/selftest/cases: add basic u-boot test

Marco Felsch (2):
barebox: add initial support
barebox-tools: add initial barebox tools support

meta/conf/distro/include/maintainers.inc | 2 +
meta/lib/oeqa/selftest/cases/barebox.py | 72 +++++++++
meta/lib/oeqa/selftest/cases/uboot.py | 40 +++++
meta/lib/oeqa/targetcontrol.py | 5 +-
meta/lib/oeqa/utils/commands.py | 22 ++-
meta/lib/oeqa/utils/qemurunner.py | 37 +++--
.../barebox/barebox-tools_2023.03.0.bb | 56 +++++++
meta/recipes-bsp/barebox/barebox.inc | 138 ++++++++++++++++++
meta/recipes-bsp/barebox/barebox_2023.03.0.bb | 3 +
9 files changed, 351 insertions(+), 24 deletions(-)
create mode 100644 meta/lib/oeqa/selftest/cases/barebox.py
create mode 100644 meta/lib/oeqa/selftest/cases/uboot.py
create mode 100644 meta/recipes-bsp/barebox/barebox-tools_2023.03.0.bb
create mode 100644 meta/recipes-bsp/barebox/barebox.inc
create mode 100644 meta/recipes-bsp/barebox/barebox_2023.03.0.bb

--
2.39.2

On Fri, 31 Mar 2023 at 12:40, Enrico Jorns <ejo@...> wrote:

v2:
* set myself as maintainer in maintainers.inc
* move doc from documentation.conf to recipe
* update to barebox v2023.03 (including fixes for musl, etc.)
* set standard configs for qemu machines to allow building them
* add better efi dir support in barebox recipe
* enable testing bootloaders in oeqa
* add test cases for barebox (and u-boot)

Thanks for persevering with this! The patchset is mostly fine (I'll
write a couple comments now), and just needs to get a verdict from the
autobuilder.

Alex

On Fri, 2023-03-31 at 12:40 +0200, Enrico Jorns 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 barebox and u-boot.

v2:
* set myself as maintainer in maintainers.inc
* move doc from documentation.conf to recipe
* update to barebox v2023.03 (including fixes for musl, etc.)
* set standard configs for qemu machines to allow building them
* add better efi dir support in barebox recipe
* enable testing bootloaders in oeqa
* add test cases for barebox (and u-boot)

Enrico Jorns (7):
barebox: set default BAREBOX_CONFIG for qemu machines
oeqa/utils/qemurunner: support ignoring vt100 escape sequences
oeqa/utils/qemurunner: simplify output parsing and make
crlf-compatible
oeqa/utils/commands: document runqemu context manager
oeqa: support passing custom boot patterns to runqemu
oeqa/selftest/cases: add barebox tests
oeqa/selftest/cases: add basic u-boot test

Marco Felsch (2):
barebox: add initial support
barebox-tools: add initial barebox tools support

Testing on the autobuilder did trigger a few issues:

on musl:

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/5023
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/6932

and some failing oe-selftests:

https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/4971
https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/5023
[there were more but look similar]

Cheers,

Richard

Hi Richard,

Am Montag, dem 03.04.2023 um 16:49 +0100 schrieb Richard Purdie:

On Fri, 2023-03-31 at 12:40 +0200, Enrico Jorns 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 barebox and u-boot.

v2:
  * set myself as maintainer in maintainers.inc
  * move doc from documentation.conf to recipe
  * update to barebox v2023.03 (including fixes for musl, etc.)
  * set standard configs for qemu machines to allow building them
  * add better efi dir support in barebox recipe
  * enable testing bootloaders in oeqa
  * add test cases for barebox (and u-boot)

Enrico Jorns (7):
  barebox: set default BAREBOX_CONFIG for qemu machines
  oeqa/utils/qemurunner: support ignoring vt100 escape sequences
  oeqa/utils/qemurunner: simplify output parsing and make
    crlf-compatible
  oeqa/utils/commands: document runqemu context manager
  oeqa: support passing custom boot patterns to runqemu
  oeqa/selftest/cases: add barebox tests
  oeqa/selftest/cases: add basic u-boot test

Marco Felsch (2):
  barebox: add initial support
  barebox-tools: add initial barebox tools support

Testing on the autobuilder did trigger a few issues:

on musl:

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/5023
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/6932

and some failing oe-selftests:

https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/4971
https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/5023
[there were more but look similar]

thank you for the autobuilder logs!

I fear we are running into a conceptional issue that I already feared we could run into (but did not
test for yet).

If I traced this down correctly, then the 'issue' is:

| NOTE: Multiple providers are available for virtual/bootloader (barebox, u-boot)
| Consider defining a PREFERRED_PROVIDER entry to match virtual/bootloader

The fitimage tests building "virtual/bootloader", silently assuming this is equal to u-boot (which
it actually was so far).

Now, the quick fix for this would be to properly set the correct PREFERRED_PROVIDER here, but I
could imagine that we run into similar issues in other builds, too.

Do you have a good solution for this at hand? Like defining a standard preferred provider for
virtual/bootloader?

I guess one could argue possibly that the mechanism does exactly what it is meant for. And a few
machines (like beaglebone-yocto or qemuloongarch) actually set the PREFERRED_PROVIDER, but not all
and this might lead to silently switching the bootloader (like in our tests).

I hope you have a better overview on the topic than I have and could give me a hint on how you would
like to see this being resolved?

Thanks in advance and best regards

Enrico

Cheers,

Richard

--
Pengutronix e.K.                           | Enrico Jörns                |
Embedded Linux Consulting & Support        | https://www.pengutronix.de/ |
Steuerwalder Str. 21                       | Phone: +49-5121-206917-180  |
31137 Hildesheim, Germany                  | Fax:   +49-5121-206917-9    |

On Mon, Apr 3, 2023 at 2:20 PM Enrico Jörns <ejo@...> wrote:

Hi Richard,

Am Montag, dem 03.04.2023 um 16:49 +0100 schrieb Richard Purdie:

On Fri, 2023-03-31 at 12:40 +0200, Enrico Jorns 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 barebox and u-boot.

v2:
* set myself as maintainer in maintainers.inc
* move doc from documentation.conf to recipe
* update to barebox v2023.03 (including fixes for musl, etc.)
* set standard configs for qemu machines to allow building them
* add better efi dir support in barebox recipe
* enable testing bootloaders in oeqa
* add test cases for barebox (and u-boot)

Enrico Jorns (7):
barebox: set default BAREBOX_CONFIG for qemu machines
oeqa/utils/qemurunner: support ignoring vt100 escape sequences
oeqa/utils/qemurunner: simplify output parsing and make
crlf-compatible
oeqa/utils/commands: document runqemu context manager
oeqa: support passing custom boot patterns to runqemu
oeqa/selftest/cases: add barebox tests
oeqa/selftest/cases: add basic u-boot test

Marco Felsch (2):
barebox: add initial support
barebox-tools: add initial barebox tools support

Testing on the autobuilder did trigger a few issues:

on musl:

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/5023
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/6932

and some failing oe-selftests:

https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/4971
https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/5023
[there were more but look similar]

thank you for the autobuilder logs!

I fear we are running into a conceptional issue that I already feared we could run into (but did not
test for yet).

If I traced this down correctly, then the 'issue' is:

| NOTE: Multiple providers are available for virtual/bootloader (barebox, u-boot)
| Consider defining a PREFERRED_PROVIDER entry to match virtual/bootloader

The fitimage tests building "virtual/bootloader", silently assuming this is equal to u-boot (which
it actually was so far).

Now, the quick fix for this would be to properly set the correct PREFERRED_PROVIDER here, but I
could imagine that we run into similar issues in other builds, too.

Do you have a good solution for this at hand? Like defining a standard preferred provider for
virtual/bootloader?

I guess one could argue possibly that the mechanism does exactly what it is meant for. And a few
machines (like beaglebone-yocto or qemuloongarch) actually set the PREFERRED_PROVIDER, but not all
and this might lead to silently switching the bootloader (like in our tests).

I hope you have a better overview on the topic than I have and could give me a hint on how you would
like to see this being resolved?

I see that it fails to build with clang
https://errors.yoctoproject.org/Errors/Details/699467/

is it buildable with clang ? if not we can pin it to use gcc always in
meta-clang but I want to make sure first.

Thanks in advance and best regards

Enrico

Cheers,

Richard

--
Pengutronix e.K. | Enrico Jörns |
Embedded Linux Consulting & Support | https://www.pengutronix.de/ |
Steuerwalder Str. 21 | Phone: +49-5121-206917-180 |
31137 Hildesheim, Germany | Fax: +49-5121-206917-9 |

Hi Khem,

Am Montag, dem 03.04.2023 um 19:33 -0700 schrieb Khem Raj:

[...]

I see that it fails to build with clang
https://errors.yoctoproject.org/Errors/Details/699467/

thanks for testing this!

is it buildable with clang ? if not we can pin it to use gcc always in
meta-clang but I want to make sure first.

barebox itself is unfortunately not buildable with clang since on some architectures like ARM32 it
uses GCC extensions that are not implemented by clang.

The barebox-tools however that are built for 'sandbox' should be buildable with clang.
It's just that when passing CROSS_COMPILE, barebox cannot guess if it has to append 'clang' or 'gcc'
suffix. The kernel seems to have an explicit handling for this by checking for "ifneq ($(LLVM),)"
and plugging together CC differently.

With barebox we could however still override the Makefile's default "CC = $(CROSS_COMPILE)gcc" when
passing CC explicitly to EXTRA_OEMAKE. We have just successfully tested this patch:

--- a/meta/recipes-bsp/barebox/barebox-tools_2023.03.0.bb
+++ b/meta/recipes-bsp/barebox/barebox-tools_2023.03.0.bb
@@ -18,6 +18,8 @@ EXTRA_OEMAKE = " \
ARCH=sandbox \
CROSS_COMPILE=${TARGET_PREFIX} -C ${S} O=${B} \
CROSS_PKG_CONFIG=pkg-config \
+ CC='${CC}' \
+ LD='${LD}' \
"


If that looks fine for you, I could add it to the recipe.


Best regards, Enrico

Thanks in advance and best regards

Enrico

Cheers,

Richard

--
Pengutronix e.K.                           | Enrico Jörns                |
Embedded Linux Consulting & Support        | https://www.pengutronix.de/ |
Steuerwalder Str. 21                       | Phone: +49-5121-206917-180  |
31137 Hildesheim, Germany                  | Fax:   +49-5121-206917-9    |

--
Pengutronix e.K.                           | Enrico Jörns                |
Embedded Linux Consulting & Support        | https://www.pengutronix.de/ |
Steuerwalder Str. 21                       | Phone: +49-5121-206917-180  |
31137 Hildesheim, Germany                  | Fax:   +49-5121-206917-9    |

On Tue, Apr 4, 2023 at 4:13 AM Enrico Jörns <ejo@...> wrote:

Hi Khem,

Am Montag, dem 03.04.2023 um 19:33 -0700 schrieb Khem Raj:

[...]

I see that it fails to build with clang
https://errors.yoctoproject.org/Errors/Details/699467/

thanks for testing this!

is it buildable with clang ? if not we can pin it to use gcc always in
meta-clang but I want to make sure first.

barebox itself is unfortunately not buildable with clang since on some architectures like ARM32 it
uses GCC extensions that are not implemented by clang.

The barebox-tools however that are built for 'sandbox' should be buildable with clang.
It's just that when passing CROSS_COMPILE, barebox cannot guess if it has to append 'clang' or 'gcc'
suffix. The kernel seems to have an explicit handling for this by checking for "ifneq ($(LLVM),)"
and plugging together CC differently.

With barebox we could however still override the Makefile's default "CC = $(CROSS_COMPILE)gcc" when
passing CC explicitly to EXTRA_OEMAKE. We have just successfully tested this patch:

--- a/meta/recipes-bsp/barebox/barebox-tools_2023.03.0.bb
+++ b/meta/recipes-bsp/barebox/barebox-tools_2023.03.0.bb
@@ -18,6 +18,8 @@ EXTRA_OEMAKE = " \
ARCH=sandbox \
CROSS_COMPILE=${TARGET_PREFIX} -C ${S} O=${B} \
CROSS_PKG_CONFIG=pkg-config \
+ CC='${CC}' \
+ LD='${LD}' \
"


If that looks fine for you, I could add it to the recipe.

yeah I was testing one with CC alone and that worked too but also
containing LD is good, so please include above
changes in next patchset

Best regards, Enrico

Thanks in advance and best regards

Enrico

Cheers,

Richard

--
Pengutronix e.K. | Enrico Jörns |
Embedded Linux Consulting & Support | https://www.pengutronix.de/ |
Steuerwalder Str. 21 | Phone: +49-5121-206917-180 |
31137 Hildesheim, Germany | Fax: +49-5121-206917-9 |

--
Pengutronix e.K. | Enrico Jörns |
Embedded Linux Consulting & Support | https://www.pengutronix.de/ |
Steuerwalder Str. 21 | Phone: +49-5121-206917-180 |
31137 Hildesheim, Germany | Fax: +49-5121-206917-9 |