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 |
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#179655): https://lists.openembedded.org/g/openembedded-core/message/179655 Mute This Topic: https://lists.openembedded.org/mt/97970644/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
