build: boot SO3 standalone on virt64 again, fix deploy races and usr clean - #338
Open
daniel-rossier wants to merge 2 commits into
Open
daniel-rossier wants to merge 2 commits into
daniel-rossier wants to merge 2 commits into
Conversation
…clean
The default virt64 configuration did not boot. Since the boot chain
became one ordered value, the default is IB_BOOT_CHAIN="uboot", and on
virt64 the uboot recipe then builds upstream qemu_arm64_defconfig — the
bare-Linux U-Boot of infrabase. That U-Boot loads the SO3 ITB and stops
on "Could not find configuration node / can't get kernel image". Before,
the default chain was "" and took virt64_defconfig. This tree now always
builds ${IB_PLATFORM}_defconfig on virt64. virt64_defconfig is linked at
a RAM address that QEMU -kernel honours, boots both SO3 and Linux, and
unlike the PIE U-Boot it can be read off the card by the boot ROM once
the QEMU bootrom-* properties are in this tree's virt.c patch.
Three independent defects, all generic, found while aligning the pos
course trees onto this build system.
do_deploy_boot_chain ran before the storage image existed. With
IB_FIRST_STAGE_FROM_CARD the virt64 chain dd's U-Boot into the raw area
of sdcard.img, but nothing ordered the task after the image creation:
on a fresh tree it failed with "no storage image ... run init_storage.sh
first", and with bsp-linux it raced filesystem:do_fs_check. It now
depends on filesystem:do_fs_check, which is a no-op when the image
exists.
Partitioning waited a fixed 2 s for the loop partition nodes. Inside the
build container they come from the host's udev and regularly take longer:
mkfs.fat then ran on a missing /dev/loopNp1, failed silently (no check),
and the next deploy died on "wrong fs type" when mounting p1. The nodes
are now polled (up to 20 s, fatal otherwise) and both mkfs calls check
their exit status.
usr.bbclass defines do_clean in Python, but the usr recipes appended
shell to it; bitbake pastes the append verbatim, so `-c clean` failed on
a SyntaxError. The shell bodies now live in named shell functions called
from a Python append. Running them for real surfaced two latent bugs,
fixed here too: the module clean ran make against a kernel tree that
does not exist before the first linux build, and (where present) the
lvgl clean of usr-so3 wiped WORKDIR/temp, which holds the running task's
own fifo.
Also: dbuild.sh now forwards IB_FORCE_ATTACH and IB_PARTITION_LAYOUT to
the container. The attach guard tells the user to set IB_FORCE_ATTACH=1,
which never reached bitbake under dbuild.sh.
In the IB_RAMFS_SOURCE = "rootfs" case, do_deploy extracts rootfs.cpio, rsyncs the user space into it and re-packs it. A failed rsync left the root-owned extracted tree behind, where the p2 path unmounts in a finally (raised in review of the edgem1 MR). Not a plain finally here: __do_rootfs_umount re-packs the tree INTO rootfs.cpio, so it would bake a half-copied user space into the archive. On failure the tree is dropped and rootfs.cpio is left as it was; the next deploy starts over from it. Verified in pos_student with IB_RAMFS_SOURCE = "rootfs": a normal deploy re-packs rootfs.cpio with the apps; a deploy made to fail (a file where the rootfs has a directory, rsync exit 23) fails the task, leaves rootfs.cpio byte-identical and removes the extracted tree.
Contributor
Author
|
Added one commit: in usr-linux do_deploy with IB_RAMFS_SOURCE = "rootfs", a failed rsync now drops the extracted rootfs tree instead of leaving it behind. This is not a plain |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
SO3 standalone on virt64 does not boot on
mainwith the default configuration. With the defaultIB_BOOT_CHAIN="uboot", the uboot recipe builds upstreamqemu_arm64_defconfigon virt64: the bare-Linux U-Boot of infrabase. That U-Boot loads the SO3 ITB and stops:Before the boot chain became one ordered value, the default was
""and tookvirt64_defconfig. This tree now always builds${IB_PLATFORM}_defconfig.virt64_defconfigboots both SO3 and Linux through-kernel, and unlike the PIE U-Boot it can be read off the card by the boot ROM once this tree's QEMUvirt.cpatch carries thebootrom-*properties. That port is not part of this PR;IB_FIRST_STAGE_FROM_CARDstays"0".The same branch carries the generic build fixes also proposed in infrabase #48 and micofe #8:
do_deploy_boot_chainvs. the storage image. WithIB_FIRST_STAGE_FROM_CARD, the virt64 chain writes U-Boot into the raw area ofsdcard.img, but nothing ordered the task after the image creation. On a fresh tree it failed ("no storage image … run init_storage.sh first"), and with bsp-linux it racedfilesystem:do_fs_check. It now depends onfilesystem:do_fs_check.mkfs. In the build container/dev/loopNp1regularly appears later, so p1 stayed unformatted and the next deploy failed mounting it. The nodes are now polled, and bothmkfscalls check their result.do_clean.usr.bbclassdefinesdo_cleanin Python and the usr recipes appended shell to it, so-c cleandied on a SyntaxError. The shell now lives in named shell functions called from a Python append. Running it for real surfaced two latent bugs, fixed here too: a module clean run against a kernel tree that does not exist yet, and (where present) an lvgl clean wipingWORKDIR/temp.dbuild.shforwardsIB_FORCE_ATTACH/IB_PARTITION_LAYOUTto the container: the attach guard's own advice (IB_FORCE_ATTACH=1) never reached bitbake underdbuild.sh.Validation:
origin/mainin a separate worktree (virt64, default chain), then deployed and booted.SO3 Init Program, shell, network up.bitbake -c clean usr-linuxpasses.virt64_defconfigwas booted in the pos course tree (same U-Boot 2022.04 and patch set), not rebuilt here.