| Message ID | 20240910184143.2820792-2-ejo@pengutronix.de |
|---|---|
| State | New |
| Headers | show |
| Series | Add barebox bootloader support (and testing) | expand |
On Tue, 10 Sept 2024 at 20:42, Enrico Jörns via lists.openembedded.org <ejo=pengutronix.de@lists.openembedded.org> wrote: > --- /dev/null > +++ b/meta/recipes-bsp/barebox/barebox_2024.08.0.bb > @@ -0,0 +1,3 @@ > +require barebox.inc > + > +SRC_URI[sha256sum] = "b08a762da8d63dd18b4f2d9f5d0a8da001b6e608d1b3eff6dcebc6a2e575d535" The checksum should be in barebox-common.inc, so it's not repeated in barebox-tools. Is there a reason to set S and B explicitly? They look like defaults to me. Also, is there a need to keep barebox.inc separate? Why not merge that into barebox.bb? Alex
Am Mittwoch, dem 11.09.2024 um 12:15 +0200 schrieb Alexander Kanavin: > On Tue, 10 Sept 2024 at 20:42, Enrico Jörns via lists.openembedded.org > <ejo=pengutronix.de@lists.openembedded.org> wrote: > > > --- /dev/null > > +++ b/meta/recipes-bsp/barebox/barebox_2024.08.0.bb > > @@ -0,0 +1,3 @@ > > +require barebox.inc > > + > > +SRC_URI[sha256sum] = "b08a762da8d63dd18b4f2d9f5d0a8da001b6e608d1b3eff6dcebc6a2e575d535" > > The checksum should be in barebox-common.inc, so it's not repeated in > barebox-tools. I kept it in the version-specific .bb file since this is the only information that would necessarily change when bumping the PV. > Is there a reason to set S and B explicitly? They look like defaults to me. S is the default actually (${BPN}-${PV}). I can omit that. B defaults to S in bitbake.conf and is only changed by build tool-specific classes. > Also, is there a need to keep barebox.inc separate? Why not merge that > into barebox.bb? Personally, I find it easier to diff recipes when they don't move with every version bump. Splitting .inc and .bb up is one way to achieve this. I see a notable number of recipes having a .inc that is required by only a single .bb. Is there any generic rule when to (not) use a .inc file? For barebox specifically, it makes the creation of recipes for a custom barebox easier since one can decide to either .bbappend the existing recipe or just create a new .bb and only require the .inc. Regards, Enrico > Alex >
Am Mittwoch, dem 11.09.2024 um 13:16 +0200 schrieb Enrico Jörns: > Am Mittwoch, dem 11.09.2024 um 12:15 +0200 schrieb Alexander Kanavin: > > On Tue, 10 Sept 2024 at 20:42, Enrico Jörns via lists.openembedded.org > > <ejo=pengutronix.de@lists.openembedded.org> wrote: > > > > > --- /dev/null > > > +++ b/meta/recipes-bsp/barebox/barebox_2024.08.0.bb > > > @@ -0,0 +1,3 @@ > > > +require barebox.inc > > > + > > > +SRC_URI[sha256sum] = "b08a762da8d63dd18b4f2d9f5d0a8da001b6e608d1b3eff6dcebc6a2e575d535" > > > > The checksum should be in barebox-common.inc, so it's not repeated in > > barebox-tools. > > I kept it in the version-specific .bb file since this is the only information that would > necessarily > change when bumping the PV. > > > Is there a reason to set S and B explicitly? They look like defaults to me. > > S is the default actually (${BPN}-${PV}). I can omit that. Just noticed that its maybe better to keep the explicit ${S} since it allows barebox recipes to have other names than just "barebox". Like "linux" is sometimes named "linux-yocto", "linux-raspberrypi", etc. /Enrico > B defaults to S in bitbake.conf and is only changed by build tool-specific classes. > > > Also, is there a need to keep barebox.inc separate? Why not merge that > > into barebox.bb? > > Personally, I find it easier to diff recipes when they don't move with every version bump. > Splitting .inc and .bb up is one way to achieve this. > > I see a notable number of recipes having a .inc that is required by only a single .bb. > Is there any generic rule when to (not) use a .inc file? > > For barebox specifically, it makes the creation of recipes for a custom barebox easier since one > can > decide to either .bbappend the existing recipe or just create a new .bb and only require the .inc. > > Regards, Enrico > > > Alex > > >
On Wed, 11 Sept 2024 at 13:16, Enrico Jörns <ejo@pengutronix.de> wrote: > I kept it in the version-specific .bb file since this is the only information that would necessarily > change when bumping the PV. Yes, but barebox and barebox-tools would have to be upgraded in lockstep, and sharing the checksum between them would ensure it actually happens. Also, the resulting diff becomes shorter. > > Also, is there a need to keep barebox.inc separate? Why not merge that > > into barebox.bb? > > Personally, I find it easier to diff recipes when they don't move with every version bump. > Splitting .inc and .bb up is one way to achieve this. > > I see a notable number of recipes having a .inc that is required by only a single .bb. > Is there any generic rule when to (not) use a .inc file? These recipes are a relic from times when oe-core had multiple versions of the same things. Over time, we merge the .inc into .bb, so there's less of those now. I prefer having everything in a single .bb, because splitting functionality between multiple files hurts readability a lot. Including .inc from a different layer is an anti-pattern, and I'd be strongly against doing that. Alex
Am Mittwoch, dem 11.09.2024 um 14:10 +0200 schrieb Alexander Kanavin: > On Wed, 11 Sept 2024 at 13:16, Enrico Jörns <ejo@pengutronix.de> wrote: > > I kept it in the version-specific .bb file since this is the only information that would > > necessarily > > change when bumping the PV. > > Yes, but barebox and barebox-tools would have to be upgraded in > lockstep, Not necessarily, despite it probably makes sense. > and sharing the checksum between them would ensure it > actually happens. Also, the resulting diff becomes shorter. By one line, but yes. > > > Also, is there a need to keep barebox.inc separate? Why not merge that > > > into barebox.bb? > > > > Personally, I find it easier to diff recipes when they don't move with every version bump. > > Splitting .inc and .bb up is one way to achieve this. > > > > I see a notable number of recipes having a .inc that is required by only a single .bb. > > Is there any generic rule when to (not) use a .inc file? > > These recipes are a relic from times when oe-core had multiple > versions of the same things. Over time, we merge the .inc into .bb, so > there's less of those now. Ok. > I prefer having everything in a single .bb, because splitting > functionality between multiple files hurts readability a lot. > > Including .inc from a different layer is an anti-pattern, and I'd be > strongly against doing that. But a commonly used one in the context of bootloaders I guess: https://github.com/search?q=%22require+recipes-bsp%2Fu-boot%2Fu-boot.inc%22&type=code What are the better options here? Inheriting the .bb? Making a .bbclass? Regards, Enrico > Alex >
On Wed, 11 Sept 2024 at 14:27, Enrico Jörns <ejo@pengutronix.de> wrote: > But a commonly used one in the context of bootloaders I guess: > > https://github.com/search?q=%22require+recipes-bsp%2Fu-boot%2Fu-boot.inc%22&type=code Sadly yes. The reason I don't like it is that changing anything in u-boot.inc in oe-core may break multiple BSP layers, and angry people will come shouting at the person who made the change, even though that file is actually private to the original recipe. > What are the better options here? > Inheriting the .bb? Making a .bbclass? Making a .bbclass, putting stuff like COMPATIBLE_MACHINE into a .bbappend, or a hard recipe fork that doesn't attempt to reuse the .inc from another layer. Alex
Am Mittwoch, dem 11.09.2024 um 16:20 +0200 schrieb Alexander Kanavin: > On Wed, 11 Sept 2024 at 14:27, Enrico Jörns <ejo@pengutronix.de> wrote: > > > But a commonly used one in the context of bootloaders I guess: > > > > https://github.com/search?q=%22require+recipes-bsp%2Fu-boot%2Fu-boot.inc%22&type=code > > Sadly yes. The reason I don't like it is that changing anything in > u-boot.inc in oe-core may break multiple BSP layers, and angry people > will come shouting at the person who made the change, even though that > file is actually private to the original recipe. > > > What are the better options here? > > Inheriting the .bb? Making a .bbclass? > > Making a .bbclass, putting stuff like COMPATIBLE_MACHINE into a > .bbappend, or a hard recipe fork that doesn't attempt to reuse the > .inc from another layer. For me, a bbclass sounds most appropriate here. For a bootloader recipe it is more likely that you will need custom SRC_URI, COMPATIBLE_MACHINE, etc than with other conventional recipes. And the need to have a hard copy of the recipe everywhere will somehow make the oe-core mainlining absurd. v6 incoming. Thanks for your input! Enrico > Alex >
diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc index 60f36a9449..1b3d485e48 100644 --- a/meta/conf/distro/include/maintainers.inc +++ b/meta/conf/distro/include/maintainers.inc @@ -54,6 +54,7 @@ RECIPE_MAINTAINER:pn-automake = "Robert Yang <liezhi.yang@windriver.com>" RECIPE_MAINTAINER:pn-avahi = "Yi Zhao <yi.zhao@windriver.com>" RECIPE_MAINTAINER:pn-babeltrace = "Alexander Kanavin <alex.kanavin@gmail.com>" RECIPE_MAINTAINER:pn-babeltrace2 = "Alexander Kanavin <alex.kanavin@gmail.com>" +RECIPE_MAINTAINER:pn-barebox = "Enrico Jörns <yocto@pengutronix.de>" RECIPE_MAINTAINER:pn-baremetal-helloworld = "Alejandro Hernandez <alejandro@enedino.org>" RECIPE_MAINTAINER:pn-base-files = "Anuj Mittal <anuj.mittal@intel.com>" RECIPE_MAINTAINER:pn-base-passwd = "Anuj Mittal <anuj.mittal@intel.com>" diff --git a/meta/recipes-bsp/barebox/barebox-common.inc b/meta/recipes-bsp/barebox/barebox-common.inc new file mode 100644 index 0000000000..3c2bc5f525 --- /dev/null +++ b/meta/recipes-bsp/barebox/barebox-common.inc @@ -0,0 +1,18 @@ +SUMMARY = "barebox is a bootloader designed for embedded systems. It runs on a variety of architectures including x86, ARM, MIPS, PowerPC and others." +DESCRIPTION = "barebox aims to be a versatile and flexible bootloader not only for booting embedded Linux systems, \ +but also for initial hardware bringup and development. \ +Users should feel right at home with a shell with UNIX-like virtual file system access to hardware, \ +Linux kernel driver API for making driver porting easier, \ +and a subset of the POSIX C library for writing more command-line utilities." +HOMEPAGE = "https://barebox.org/" +SECTION = "bootloaders" + +LICENSE = "GPL-2.0-only" +LIC_FILES_CHKSUM = "file://COPYING;md5=f5125d13e000b9ca1f0d3364286c4192" + +DEPENDS = "bison-native flex-native" + +SRC_URI = "https://barebox.org/download/barebox-${PV}.tar.bz2" + +S = "${WORKDIR}/barebox-${PV}" +B = "${WORKDIR}/build" diff --git a/meta/recipes-bsp/barebox/barebox.inc b/meta/recipes-bsp/barebox/barebox.inc new file mode 100644 index 0000000000..5db10a0e38 --- /dev/null +++ b/meta/recipes-bsp/barebox/barebox.inc @@ -0,0 +1,140 @@ +require barebox-common.inc + +PROVIDES = "virtual/bootloader" + +PACKAGE_ARCH = "${MACHINE_ARCH}" + +require conf/image-uefi.conf + +inherit kernel-arch deploy cml1 pkgconfig + +# For some platforms and configuration, the barebox build process will require +# additional host tools that can be activated/deactivated here. +PACKAGECONFIG ??= "openssl libusb fit" + +PACKAGECONFIG[openssl] = ",,openssl-native" +PACKAGECONFIG[libusb] = ",,libusb1-native" +PACKAGECONFIG[fit] = ",,u-boot-tools-native dtc-native" + +export KBUILD_BUILD_USER ?= "oe-user" +export KBUILD_BUILD_HOST ?= "oe-host" + +# unlike the kernel, barebox may build against host tools like openssl +export HOST_EXTRACFLAGS + +def get_layer_rev(path): + try: + rev, _ = bb.process.run("git describe --match='' --always --dirty --broken", cwd=path) + except bb.process.ExecutionError: + rev = "" + return rev.strip() + +BAREBOX_BUILDSYSTEM_VERSION[doc] = "Build system version to add to the barebox image. By default this is the git description of the containing layer." +BAREBOX_BUILDSYSTEM_VERSION ??= "${@get_layer_rev(os.path.dirname(d.getVar('FILE')))}" + +BAREBOX_FIRMWARE_DIR[doc] = "Overwrite barebox' firmware blobs search directory (CONFIG_EXTRA_FIRMWARE_DIR) with this path, default ${B}/firmware" +BAREBOX_FIRMWARE_DIR ??= "${B}/firmware" + +EXTRA_OEMAKE = " \ + CROSS_COMPILE=${TARGET_PREFIX} -C ${S} O=${B} \ + BUILDSYSTEM_VERSION=${BAREBOX_BUILDSYSTEM_VERSION} \ + CONFIG_EXTRA_FIRMWARE_DIR=${BAREBOX_FIRMWARE_DIR} \ + PKG_CONFIG=pkg-config-native \ + CROSS_PKG_CONFIG=pkg-config \ +" + +BAREBOX_CONFIG[doc] = "The barebox kconfig defconfig file. Not used if a file called defconfig is added to the SRC_URI." +BAREBOX_CONFIG ?= "" + +# prevent from acting as non-buildable provider +python () { + bareboxconfig = d.getVar('BAREBOX_CONFIG') + bareboxdefconfig = 'file://defconfig' in d.getVar('SRC_URI') + + if not bareboxconfig and not bareboxdefconfig: + raise bb.parse.SkipRecipe("BAREBOX_CONFIG must be set in the %s machine configuration or file://defconfig must be given in SRC_URI." % d.getVar("MACHINE")) +} + +do_configure() { + if [ -e ${WORKDIR}/defconfig ]; then + cp ${WORKDIR}/defconfig ${B}/.config + else + if [ -n "${BAREBOX_CONFIG}" ]; then + oe_runmake ${BAREBOX_CONFIG} + else + bbfatal "No defconfig given. Either add file 'file://defconfig' to SRC_URI or set BAREBOX_CONFIG" + fi + fi + + ${S}/scripts/kconfig/merge_config.sh -m .config ${@" ".join(find_cfgs(d))} + cml1_do_configure +} + +BAREBOX_ENV_DIR[doc] = "Overlay the barebox built-in environment with the environment provided by the BSP if specified." +BAREBOX_ENV_DIR ??= "${WORKDIR}/env/" + +do_compile () { + export userccflags="${TARGET_LDFLAGS}${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}" + unset LDFLAGS + unset CFLAGS + unset CPPFLAGS + unset CXXFLAGS + unset MACHINE + + if [ -d ${BAREBOX_ENV_DIR} ]; then + BAREBOX_DEFAULT_ENV="$(grep ^CONFIG_DEFAULT_ENVIRONMENT_PATH .config | cut -d '=' -f 2 | tr -d '"')" + oe_runmake CONFIG_DEFAULT_ENVIRONMENT_PATH="\"${BAREBOX_DEFAULT_ENV} ${BAREBOX_ENV_DIR}\"" + else + oe_runmake + fi +} + +BAREBOX_BINARY[doc] = "Specify the barebox binary to install. If not specified all barebox artifacts are installed." +BAREBOX_BINARY ??= "${@'barebox.efi' if d.getVar('EFI_PROVIDER') == 'barebox' else ''}" +BAREBOX_SUFFIX[doc] = "Specify the suffix for ${BAREBOX_IMAGE}." +BAREBOX_SUFFIX ??= "img" +BAREBOX_IMAGE[doc] = "A unique barebox image name. Unused if ${BAREBOX_BINARY} is not set." +BAREBOX_IMAGE_DEFAULT ?= "${PN}-${MACHINE}-${PV}-${PR}.${BAREBOX_SUFFIX}" +BAREBOX_IMAGE ?= "${@'${EFI_BOOT_IMAGE}' if d.getVar('EFI_PROVIDER') == 'barebox' else '${BAREBOX_IMAGE_DEFAULT}'}" + +BAREBOX_INSTALL_PATH ?= "${@'${EFI_FILES_PATH}' if d.getVar('EFI_PROVIDER') == 'barebox' else '/boot'}" + +do_install () { + if [ -n "${BAREBOX_BINARY}" ]; then + + BAREBOX_BIN=${B}/${BAREBOX_BINARY} + if [ ! -f "${BAREBOX_BIN}" ]; then + BAREBOX_BIN=${B}/images/${BAREBOX_BINARY} + fi + if [ ! -f "${BAREBOX_BIN}" ]; then + bbfatal "Failed to locate ${BAREBOX_BINARY}" + fi + + install -D -m 644 ${BAREBOX_BIN} ${D}${BAREBOX_INSTALL_PATH}/${BAREBOX_IMAGE} + ln -sf ${BAREBOX_IMAGE} ${D}${BAREBOX_INSTALL_PATH}/${BAREBOX_BINARY} + else + install -d ${D}${BAREBOX_INSTALL_PATH}/ + for image in $(cat ${B}/barebox-flash-images); do + install -m 644 ${B}/${image} ${D}${BAREBOX_INSTALL_PATH}/ + done + fi +} +FILES:${PN} = "${BAREBOX_INSTALL_PATH}" + +do_deploy () { + if [ -n "${BAREBOX_BINARY}" ]; then + + BAREBOX_BIN=${B}/${BAREBOX_BINARY} + if [ ! -f "${BAREBOX_BIN}" ]; then + BAREBOX_BIN=${B}/images/${BAREBOX_BINARY} + fi + + install -D -m 644 ${BAREBOX_BIN} ${DEPLOYDIR}/${BAREBOX_IMAGE} + ln -sf ${BAREBOX_IMAGE} ${DEPLOYDIR}/${BAREBOX_BINARY} + else + for image in $(cat ${B}/barebox-flash-images); do + cp ${B}/${image} ${DEPLOYDIR} + done + fi +} +addtask deploy after do_compile diff --git a/meta/recipes-bsp/barebox/barebox_2024.08.0.bb b/meta/recipes-bsp/barebox/barebox_2024.08.0.bb new file mode 100644 index 0000000000..1a7bbbccaa --- /dev/null +++ b/meta/recipes-bsp/barebox/barebox_2024.08.0.bb @@ -0,0 +1,3 @@ +require barebox.inc + +SRC_URI[sha256sum] = "b08a762da8d63dd18b4f2d9f5d0a8da001b6e608d1b3eff6dcebc6a2e575d535"