Defcon 34 badge as a hardware target. Picking it fills in the crates, features and flags the badge build needs, so Build sends the documented cargo xtask baosec-lite command. It is offered for in-tree builds only for now.
In-tree builds can pass extra arguments to cargo xtask: features, kernel features, and switches, set under Baochip > In Tree in settings. Switches work with or without the leading --
Out-of-tree projects can build and flash for baosec: the build produces swap.uf2 rather than apps.uf2, and kernel sync fetches from the board's own CI directory
New kernel mode app-only, which flashes just the image your project builds and leaves the kernel already on the board in place
Build • Flash • Boot - builds, flashes, and restarts the board without opening a monitor
Warning when a built or flashed .uf2 is too big for its dabao flash region (oversized images are silently truncated and leave the board running no app)
Warning when rustc is not a stable build; nightly, beta, and dev toolchains are unsupported and now say so up front rather than failing in the toolchain download
Out-of-tree projects can be a cargo workspace: pick which crates to build and they are built together into one apps.uf2. A project with a single crate needs no picking
Warning before flashing when the attached board reports a different type than the hardware target - the bootloader is asked which board it is, and a mismatch can be overridden or silenced via baochip.checkBoardTypeBeforeFlash
Changed
Build • Flash • Monitor is now called Build • Flash • Boot • Monitor - it always booted the board after flashing
The app picker now selects several apps at once, starting from what is already set; previously it replaced the whole setting with one app
The app setting shows a warning when it names something the project does not have, rather than silently building without it
The build target is now called the hardware target throughout the UI, matching xous-core and keeping it distinct from the Rust toolchain target. It is no longer assumed to be dabao: the first build, flash, or app pick asks once
The app picker now offers only what can build for the selected hardware target: apps and crates whose manifest declares its board- feature. Anything selected that cannot build stays listed and checked, labelled with why, so it can be unchecked there; unchecking everything clears the list
Flashing now sends only the images the selected hardware target builds - loader/xous/apps for dabao, loader/xous/swap for baosec
Fixed
Python tools now run with the extension virtual environment interpreter directly. uv only finds a virtual environment through a project file, which the storage folder does not have, so uv run fell back to another Python and every command failed with ModuleNotFoundError even after a successful install
The manual kernel files folder can be a relative path, taken from the project folder, so a workspace setting shared with the repository works on every machine. Relative paths used to be resolved against whatever directory the editor was started from, and silently found nothing
The app list can include service and library crates (not just apps) in in-tree build configurations.
Boot after flashing sometimes did nothing while the log claimed success; it is now confirmed and resent if the board is still in the bootloader
New app template now pins getrandom = "=0.2.12"; unpinned, it resolved past the patch and failed to build
Builds and cleans now wait for the terminal to be ready, so a Python environment activating in it can no longer kill them on startup
Building or flashing without a hardware target set reported "No build target set" while the status bar showed dabao; the extension now asks which board you have the first time it needs to know, and remembers the answer
