[{"data":1,"prerenderedAt":974},["ShallowReactive",2],{"search-index":3,"dev-yocto-layers-maintainable-strategy-2026":101},[4,8,12,17,21,25,29,33,37,42,47,52,57,62,67,72,77,82,87,92,97],{"_path":5,"title":6,"description":7},"/dev/eu-cyber-resilience-act-firmware-evidence-pack","Eu Cyber Resilience Act Firmware Evidence Pack","title: \"EU Cyber Resilience Act in Practice for Firmware Teams: Engineering Tasks and Evidence Pack\"\ndescription: \"Practical breakdown of the EU Cyber Resilience Act requirements for embedded firmware teams, covering technical obligations, SBOM requirements, vulnerability handling, and the evidence pack needed for compliance.\"\ndate: 2026-04-19T08:00:00Z\nlastmod: 2026-04-19T08:00:00Z\ndraft: false\nhero: \"/images/hero/eu-cyber-resilience-act-firmware-evidence-pack-1600x900.jpg\"\ntags:",{"_path":9,"title":10,"description":11},"/dev/pkg/firmware-sboms-spdx-cyclonedx-2026","Firmware Sboms Spdx Cyclonedx 2026","title: \"Firmware SBOMs in 2026: SPDX vs CycloneDX, What to Publish, and What to Automate\"\ndescription: \"Practical comparison of SPDX and CycloneDX for firmware SBOMs, covering what to include, automation approaches, tooling, and publication strategies for embedded Linux products.\"\ndate: 2026-04-19T08:00:00Z\nlastmod: 2026-04-19T08:00:00Z\ndraft: false\nhero: \"/images/hero/firmware-sboms-spdx-cyclonedx-2026-1600x900.jpg\"\ntags:",{"_path":13,"title":14,"description":15,"date":16},"/dev/pkg/spdx-3-0-embedded-builds-practical","SPDX 3.0 for Embedded Builds: Packages, Files, and Relationships Engineers Actually Use","Practical guide to SPDX 3.0 for embedded Linux, covering the data model, package and file elements, relationship types, and how to produce useful SPDX documents from Yocto and Buildroot builds.","2026-04-19T08:00:00Z",{"_path":18,"title":19,"description":20},"/dev/slsa-build-provenance-firmware-sign-verify","Slsa Build Provenance Firmware Sign Verify","title: \"SLSA Build Provenance for Firmware: What to Collect, How to Sign, How to Verify\"\ndescription: \"Practical implementation guide for SLSA build provenance in firmware pipelines, covering provenance generation, signing with Sigstore, verification workflows, and integration with SBOMs.\"\ndate: 2026-04-19T08:00:00Z\nlastmod: 2026-04-19T08:00:00Z\ndraft: false\nhero: \"/images/hero/slsa-build-provenance-firmware-sign-verify-1600x900.jpg\"\ntags:",{"_path":22,"title":23,"description":24},"/dev/vex-csaf-embedded-not-affected-scale","Vex Csaf Embedded Not Affected Scale","title: \"VEX and CSAF for Embedded Devices: Publishing \"Not Affected\" at Scale\"\ndescription: \"How to produce and distribute VEX documents and CSAF advisories for embedded firmware, enabling downstream consumers to filter false positives from vulnerability scans.\"\ndate: 2026-04-15T20:03:00Z\nlastmod: 2026-04-15T20:03:00Z\ndraft: false\nhero: \"/images/hero/vex-csaf-embedded-not-affected-scale-1600x900.jpg\"\ntags:",{"_path":26,"title":27,"description":28},"/dev/yocto-5-2-walnascar-highlights-embedded-2026","Yocto 5 2 Walnascar Highlights Embedded 2026","title: \"Yocto 5.2 \"Walnascar\" Highlights for Embedded Teams: Toolchain, Security, SPDX 3.0\"\ndescription: \"Key changes in Yocto 5.2 Walnascar relevant to embedded product teams, covering toolchain updates, security improvements, SPDX 3.0 support, and migration notes.\"\ndate: 2026-04-12T08:14:00Z\nlastmod: 2026-04-12T08:14:00Z\ndraft: false\nhero: \"/images/hero/yocto-5-2-walnascar-highlights-embedded-2026-1600x900.jpg\"\ntags:",{"_path":30,"title":31,"description":32},"/dev/yocto-esdk-faster-iteration-2026","Yocto Esdk Faster Iteration 2026","title: \"Yocto eSDK in 2026: Faster Application Iteration Without Full Rebuild Cycles\"\ndescription: \"How to use Yocto's extensible SDK to speed up application development by building and testing packages without running full BitBake builds.\"\ndate: 2026-04-11T07:09:00Z\nlastmod: 2026-04-11T07:09:00Z\ndraft: false\nhero: \"/images/hero/yocto-esdk-faster-iteration-2026-1600x900.jpg\"\ntags:",{"_path":34,"title":35,"description":36},"/dev/yocto-layers-maintainable-strategy-2026","Yocto Layers Maintainable Strategy 2026","title: \"Yocto Layers That Stay Maintainable: Layer Model, Naming, and Upgrade Strategy (2026)\"\ndescription: \"Practical guidance on structuring Yocto layers for long-term maintainability, covering layer boundaries, naming conventions, version pinning, and upgrade workflows.\"\ndate: 2026-04-07T13:41:00Z\nlastmod: 2026-04-07T13:41:00Z\ndraft: false\nhero: \"/images/hero/yocto-layers-maintainable-strategy-2026-1600x900.jpg\"\ntags:",{"_path":38,"title":39,"description":40,"date":41},"/doc/bootlin-toolchains-arm-riscv-2026","Bootlin Toolchains in Practice: Picking the Right Prebuilt Toolchain for ARM and RISC-V","How to select and validate Bootlin prebuilt cross-compilation toolchains for ARM Cortex-A, Cortex-M, and RISC-V targets in embedded Linux projects.","2026-03-10T16:05:00Z",{"_path":43,"title":44,"description":45,"date":46},"/doc/buildroot-vs-yocto-2026","Buildroot vs Yocto in 2026: Which Embedded Linux Build System Fits Your Product Lifecycle?","A detailed comparison of Buildroot and Yocto for embedded Linux, covering build performance, long-term maintenance, layer ecosystems, and practical decision criteria for product teams in 2026.","2026-03-05T08:12:00Z",{"_path":48,"title":49,"description":50,"date":51},"/doc/cross-compilation-toolchain-triplet-clib-2026","Cross-Compilation in 2026: Choosing a Toolchain, Target Triplet, and C Library (glibc vs musl)","Practical guidance on selecting cross-compilation toolchains for embedded Linux, understanding target triplets, and choosing between glibc and musl for your production firmware.","2026-03-07T07:43:00Z",{"_path":53,"title":54,"description":55,"date":56},"/doc/erofs-vs-squashfs-2026","EROFS in 2026: When a Read-Only Filesystem Beats SquashFS (Performance, Dedupe, Updates)","Detailed comparison of EROFS and SquashFS for embedded Linux in 2026, covering read performance, compression ratios, deduplication, and integration with OTA update schemes.","2026-03-22T14:22:00Z",{"_path":58,"title":59,"description":60,"date":61},"/doc/ota-updates-rauc-swupdate-mender-2026","OTA Updates in 2026: RAUC vs SWUpdate vs Mender for Robust Fleet Management","Comparison of RAUC, SWUpdate, and Mender for embedded Linux OTA updates, covering update models, rollback strategies, fleet management, and integration with Yocto and Buildroot.","2026-03-28T19:07:00Z",{"_path":63,"title":64,"description":65,"date":66},"/doc/plat/device-tree-debugging-overlays-validation-2026","Device Tree Debugging for Embedded Linux: Overlays, Common Errors, and Validation","Practical guide to debugging device tree issues in embedded Linux, covering overlay mechanics, common DTS errors, validation tools, and runtime debugging techniques.","2026-04-05T06:58:00Z",{"_path":68,"title":69,"description":70,"date":71},"/doc/plat/porting-checklist-bootloader-kernel-rootfs-2026","Porting Checklist 2026: Bootloader → Kernel → RootFS for New Boards","Complete checklist for porting embedded Linux to a new board, from bootloader bring-up through kernel configuration to root filesystem validation, with practical tips for each stage.","2026-04-02T15:16:00Z",{"_path":73,"title":74,"description":75,"date":76},"/doc/real-time-linux-preempt-rt-latency-2026","Real-Time Linux in 2026: PREEMPT_RT Basics, Tuning, and How to Prove Latency","Practical guide to PREEMPT_RT on embedded Linux covering kernel configuration, IRQ threading, latency measurement with cyclictest, and tuning techniques for deterministic response times.","2026-03-23T05:48:00Z",{"_path":78,"title":79,"description":80,"date":81},"/doc/rootfs-integrity-dm-verity-immutable-images","Root Filesystem Integrity with dm-verity: Design Patterns for Immutable Images","How to design and implement dm-verity-protected root filesystems for embedded Linux, covering hash tree generation, kernel integration, error handling, and update strategies.","2026-03-19T08:56:00Z",{"_path":83,"title":84,"description":85,"date":86},"/doc/rtos-vs-embedded-linux-zephyr-2026","RTOS vs Embedded Linux in 2026: Where Zephyr Fits and Where Full Linux Wins","Practical comparison of RTOS (Zephyr, FreeRTOS) and embedded Linux for product design, covering latency, memory footprint, ecosystem maturity, and hybrid architectures.","2026-03-30T09:35:00Z",{"_path":88,"title":89,"description":90,"date":91},"/doc/secure-boot-uboot-fit-signatures-chain-of-trust","Secure Boot with U-Boot FIT Signatures: A Practical Chain-of-Trust Walkthrough","Step-by-step guide to implementing secure boot using U-Boot FIT image signatures, from key generation through verified boot to failure handling on embedded Linux targets.","2026-03-14T06:29:00Z",{"_path":93,"title":94,"description":95,"date":96},"/doc/verified-boot-patterns-uboot-keys-failure-modes","Verified Boot Patterns in U-Boot: What to Verify, Where Keys Live, and Failure Modes","Deep dive into U-Boot verified boot patterns covering signature scopes, key storage options, common failure modes, and practical debugging techniques for embedded Linux platforms.","2026-03-16T18:11:00Z",{"_path":98,"title":99,"description":100},"/image-manifest","ProteanOS Image Manifest","This document lists all hero and supporting images needed for the website.",{"_path":34,"_dir":102,"_draft":103,"_partial":103,"_locale":104,"title":35,"description":36,"body":105,"_type":968,"_id":969,"_source":970,"_file":971,"_stem":972,"_extension":973},"dev",false,"",{"type":106,"children":107,"toc":946},"root",[108,113,119,139,142,147,154,168,173,179,184,193,200,219,245,255,272,289,295,307,385,391,411,449,454,460,470,509,515,557,563,584,714,727,733,738,744,749,755,774,780,800,806,811,817,822,828,840,859,871,876,882,912,917,922,928,940],{"type":109,"tag":110,"props":111,"children":112},"element","hr",{},[],{"type":109,"tag":114,"props":115,"children":116},"p",{},[117],{"type":118,"value":36},"text",{"type":109,"tag":120,"props":121,"children":122},"ul",{},[123,129,134],{"type":109,"tag":124,"props":125,"children":126},"li",{},[127],{"type":118,"value":128},"Embedded Linux",{"type":109,"tag":124,"props":130,"children":131},{},[132],{"type":118,"value":133},"ProteanOS",{"type":109,"tag":124,"props":135,"children":136},{},[137],{"type":118,"value":138},"Yocto\ncategory: dev",{"type":109,"tag":110,"props":140,"children":141},{},[],{"type":109,"tag":114,"props":143,"children":144},{},[145],{"type":118,"value":146},"Yocto's layer model is simultaneously its greatest strength and its most common source of technical debt. A well-structured layer stack makes upgrades predictable and merges clean. A poorly structured one makes every Yocto release upgrade a multi-week ordeal. After maintaining layer stacks across several Yocto LTS transitions, clear patterns emerge for what works and what does not.",{"type":109,"tag":148,"props":149,"children":151},"h2",{"id":150},"layer-model-fundamentals",[152],{"type":118,"value":153},"Layer model fundamentals",{"type":109,"tag":114,"props":155,"children":156},{},[157,159,166],{"type":118,"value":158},"A Yocto layer is a directory containing recipes, configuration, and classes that modify the build. Layers compose through ",{"type":109,"tag":160,"props":161,"children":163},"code",{"className":162},[],[164],{"type":118,"value":165},"bblayers.conf",{"type":118,"value":167},", and their priority determines which recipes and configurations win when conflicts exist.",{"type":109,"tag":114,"props":169,"children":170},{},[171],{"type":118,"value":172},"The key point most teams miss: layers are not just a code organisation mechanism. They define responsibility boundaries. Each layer should be owned by one team or organisation and should encapsulate one concern. When that discipline breaks down - when BSP code drifts into the product layer, or when the distro layer starts carrying per-board hacks - upgrade cycles become painful and cross-product reuse stops being realistic.",{"type":109,"tag":148,"props":174,"children":176},{"id":175},"recommended-layer-structure",[177],{"type":118,"value":178},"Recommended layer structure",{"type":109,"tag":114,"props":180,"children":181},{},[182],{"type":118,"value":183},"A typical product build uses four to six layers:",{"type":109,"tag":185,"props":186,"children":188},"pre",{"code":187},"meta-poky              # Yocto reference distribution (or your distro layer)\nmeta-openembedded      # Community packages (meta-oe, meta-python, etc.)\nmeta-silicon-vendor    # SoC BSP (meta-freescale, meta-ti, meta-rockchip)\nmeta-product           # Your product-specific recipes and configuration\nmeta-product-bsp       # Your board-specific BSP customizations\n",[189],{"type":109,"tag":160,"props":190,"children":191},{"__ignoreMap":104},[192],{"type":118,"value":187},{"type":109,"tag":194,"props":195,"children":197},"h3",{"id":196},"what-goes-where",[198],{"type":118,"value":199},"What goes where",{"type":109,"tag":114,"props":201,"children":202},{},[203,217],{"type":109,"tag":204,"props":205,"children":206},"strong",{},[207,209,215],{"type":118,"value":208},"Distro layer (",{"type":109,"tag":160,"props":210,"children":212},{"className":211},[],[213],{"type":118,"value":214},"meta-poky",{"type":118,"value":216}," or custom):",{"type":118,"value":218}," Distribution policies - init system choice, package format, default compiler flags, security hardening options. Do not put product-specific settings here.",{"type":109,"tag":114,"props":220,"children":221},{},[222,235,237,243],{"type":109,"tag":204,"props":223,"children":224},{},[225,227,233],{"type":118,"value":226},"Community layers (",{"type":109,"tag":160,"props":228,"children":230},{"className":229},[],[231],{"type":118,"value":232},"meta-openembedded",{"type":118,"value":234},"):",{"type":118,"value":236}," Upstream-maintained recipes for common packages. Pin to a specific branch matching your Yocto release. Do not modify recipes in-place; use ",{"type":109,"tag":160,"props":238,"children":240},{"className":239},[],[241],{"type":118,"value":242},".bbappend",{"type":118,"value":244}," in your product layer.",{"type":109,"tag":114,"props":246,"children":247},{},[248,253],{"type":109,"tag":204,"props":249,"children":250},{},[251],{"type":118,"value":252},"Vendor BSP layer:",{"type":118,"value":254}," SoC-specific kernel, bootloader, and driver recipes. Ideally, track the vendor's maintained branch. Accept that vendor layers often have quality issues and plan to carry patches.",{"type":109,"tag":114,"props":256,"children":257},{},[258,270],{"type":109,"tag":204,"props":259,"children":260},{},[261,263,269],{"type":118,"value":262},"Product layer (",{"type":109,"tag":160,"props":264,"children":266},{"className":265},[],[267],{"type":118,"value":268},"meta-product",{"type":118,"value":234},{"type":118,"value":271}," Your application recipes, systemd service files, configuration files, image recipes. This is where most of your development happens.",{"type":109,"tag":114,"props":273,"children":274},{},[275,287],{"type":109,"tag":204,"props":276,"children":277},{},[278,280,286],{"type":118,"value":279},"Product BSP layer (",{"type":109,"tag":160,"props":281,"children":283},{"className":282},[],[284],{"type":118,"value":285},"meta-product-bsp",{"type":118,"value":234},{"type":118,"value":288}," Board-specific device trees, kernel configuration fragments, bootloader patches that are specific to your hardware. Separate from the product layer to allow multiple boards to share application recipes.",{"type":109,"tag":148,"props":290,"children":292},{"id":291},"naming-conventions",[293],{"type":118,"value":294},"Naming conventions",{"type":109,"tag":114,"props":296,"children":297},{},[298,300,305],{"type":118,"value":299},"Good naming prevents confusion when you have 15 layers in ",{"type":109,"tag":160,"props":301,"children":303},{"className":302},[],[304],{"type":118,"value":165},{"type":118,"value":306},":",{"type":109,"tag":120,"props":308,"children":309},{},[310,337,355,380],{"type":109,"tag":124,"props":311,"children":312},{},[313,315,321,323,329,331],{"type":118,"value":314},"Prefix vendor BSP layers with ",{"type":109,"tag":160,"props":316,"children":318},{"className":317},[],[319],{"type":118,"value":320},"meta-",{"type":118,"value":322}," + vendor name: ",{"type":109,"tag":160,"props":324,"children":326},{"className":325},[],[327],{"type":118,"value":328},"meta-freescale",{"type":118,"value":330},", ",{"type":109,"tag":160,"props":332,"children":334},{"className":333},[],[335],{"type":118,"value":336},"meta-ti",{"type":109,"tag":124,"props":338,"children":339},{},[340,342,347,349],{"type":118,"value":341},"Prefix your layers with ",{"type":109,"tag":160,"props":343,"children":345},{"className":344},[],[346],{"type":118,"value":320},{"type":118,"value":348}," + company or product: ",{"type":109,"tag":160,"props":350,"children":352},{"className":351},[],[353],{"type":118,"value":354},"meta-acme-product",{"type":109,"tag":124,"props":356,"children":357},{},[358,360,366,367,373,374],{"type":118,"value":359},"Use suffixes for variants: ",{"type":109,"tag":160,"props":361,"children":363},{"className":362},[],[364],{"type":118,"value":365},"meta-acme-bsp",{"type":118,"value":330},{"type":109,"tag":160,"props":368,"children":370},{"className":369},[],[371],{"type":118,"value":372},"meta-acme-distro",{"type":118,"value":330},{"type":109,"tag":160,"props":375,"children":377},{"className":376},[],[378],{"type":118,"value":379},"meta-acme-apps",{"type":109,"tag":124,"props":381,"children":382},{},[383],{"type":118,"value":384},"Layer names should be globally unique within your organisation",{"type":109,"tag":148,"props":386,"children":388},{"id":387},"layer-priorities",[389],{"type":118,"value":390},"Layer priorities",{"type":109,"tag":114,"props":392,"children":393},{},[394,396,402,404,410],{"type":118,"value":395},"Set ",{"type":109,"tag":160,"props":397,"children":399},{"className":398},[],[400],{"type":118,"value":401},"BBFILE_PRIORITY",{"type":118,"value":403}," explicitly in each layer's ",{"type":109,"tag":160,"props":405,"children":407},{"className":406},[],[408],{"type":118,"value":409},"conf/layer.conf",{"type":118,"value":306},{"type":109,"tag":185,"props":412,"children":416},{"code":413,"language":414,"meta":104,"className":415,"style":104},"BBFILE_PRIORITY_meta-product = \"10\"\nBBFILE_PRIORITY_meta-product-bsp = \"9\"\nBBFILE_PRIORITY_meta-silicon-vendor = \"5\"\n","bitbake","language-bitbake shiki shiki-themes github-dark",[417],{"type":109,"tag":160,"props":418,"children":419},{"__ignoreMap":104},[420,431,440],{"type":109,"tag":421,"props":422,"children":425},"span",{"class":423,"line":424},"line",1,[426],{"type":109,"tag":421,"props":427,"children":428},{},[429],{"type":118,"value":430},"BBFILE_PRIORITY_meta-product = \"10\"\n",{"type":109,"tag":421,"props":432,"children":434},{"class":423,"line":433},2,[435],{"type":109,"tag":421,"props":436,"children":437},{},[438],{"type":118,"value":439},"BBFILE_PRIORITY_meta-product-bsp = \"9\"\n",{"type":109,"tag":421,"props":441,"children":443},{"class":423,"line":442},3,[444],{"type":109,"tag":421,"props":445,"children":446},{},[447],{"type":118,"value":448},"BBFILE_PRIORITY_meta-silicon-vendor = \"5\"\n",{"type":109,"tag":114,"props":450,"children":451},{},[452],{"type":118,"value":453},"Higher priority layers override lower ones. Your product layer should have the highest priority so your customizations always win.",{"type":109,"tag":148,"props":455,"children":457},{"id":456},"the-bbappend-problem",[458],{"type":118,"value":459},"The bbappend problem",{"type":109,"tag":114,"props":461,"children":462},{},[463,468],{"type":109,"tag":160,"props":464,"children":466},{"className":465},[],[467],{"type":118,"value":242},{"type":118,"value":469}," files modify recipes from other layers. They are powerful but fragile:",{"type":109,"tag":120,"props":471,"children":472},{},[473,485,497],{"type":109,"tag":124,"props":474,"children":475},{},[476,478,483],{"type":118,"value":477},"A ",{"type":109,"tag":160,"props":479,"children":481},{"className":480},[],[482],{"type":118,"value":242},{"type":118,"value":484}," breaks if the recipe version in the base layer changes",{"type":109,"tag":124,"props":486,"children":487},{},[488,490,495],{"type":118,"value":489},"Finding which ",{"type":109,"tag":160,"props":491,"children":493},{"className":492},[],[494],{"type":118,"value":242},{"type":118,"value":496}," files affect a recipe requires searching across all layers",{"type":109,"tag":124,"props":498,"children":499},{},[500,502,507],{"type":118,"value":501},"Too many ",{"type":109,"tag":160,"props":503,"children":505},{"className":504},[],[506],{"type":118,"value":242},{"type":118,"value":508}," files make it hard to understand what the final recipe actually does",{"type":109,"tag":194,"props":510,"children":512},{"id":511},"keeping-bbappend-files-under-control",[513],{"type":118,"value":514},"Keeping bbappend files under control",{"type":109,"tag":114,"props":516,"children":517},{},[518,520,525,527,532,534,540,542,548,550,555],{"type":118,"value":519},"Minimise them. If you need significant changes to a recipe, fork it into your product layer rather than stacking ",{"type":109,"tag":160,"props":521,"children":523},{"className":522},[],[524],{"type":118,"value":242},{"type":118,"value":526}," files that are difficult to reason about later. Pin the recipe version in the ",{"type":109,"tag":160,"props":528,"children":530},{"className":529},[],[531],{"type":118,"value":242},{"type":118,"value":533}," filename: ",{"type":109,"tag":160,"props":535,"children":537},{"className":536},[],[538],{"type":118,"value":539},"package_1.2.3.bbappend",{"type":118,"value":541}," rather than ",{"type":109,"tag":160,"props":543,"children":545},{"className":544},[],[546],{"type":118,"value":547},"package_%.bbappend",{"type":118,"value":549},". The percentage wildcard matches any version, which seems helpful until an upstream recipe changes behaviour in a minor bump and your override silently applies to something it was not written for. Add a comment at the top of each ",{"type":109,"tag":160,"props":551,"children":553},{"className":552},[],[554],{"type":118,"value":242},{"type":118,"value":556}," explaining why it exists. Future maintainers will not know the context, and even you will not remember in eighteen months.",{"type":109,"tag":148,"props":558,"children":560},{"id":559},"version-pinning-and-reproducibility",[561],{"type":118,"value":562},"Version pinning and reproducibility",{"type":109,"tag":114,"props":564,"children":565},{},[566,568,574,576,582],{"type":118,"value":567},"Pin every layer to a specific commit or tag in your build manifest (",{"type":109,"tag":160,"props":569,"children":571},{"className":570},[],[572],{"type":118,"value":573},"repo",{"type":118,"value":575}," manifest or ",{"type":109,"tag":160,"props":577,"children":579},{"className":578},[],[580],{"type":118,"value":581},"kas",{"type":118,"value":583}," configuration):",{"type":109,"tag":185,"props":585,"children":589},{"code":586,"language":587,"meta":104,"className":588,"style":104},"# kas configuration example\nrepos:\n  poky:\n    url: \"https://git.yoctoproject.org/poky\"\n    refspec: \"scarthgap-5.0.5\"\n  meta-openembedded:\n    url: \"https://git.openembedded.org/meta-openembedded\"\n    refspec: \"scarthgap\"\n","yaml","language-yaml shiki shiki-themes github-dark",[590],{"type":109,"tag":160,"props":591,"children":592},{"__ignoreMap":104},[593,602,617,629,649,667,680,697],{"type":109,"tag":421,"props":594,"children":595},{"class":423,"line":424},[596],{"type":109,"tag":421,"props":597,"children":599},{"style":598},"--shiki-default:#6A737D",[600],{"type":118,"value":601},"# kas configuration example\n",{"type":109,"tag":421,"props":603,"children":604},{"class":423,"line":433},[605,611],{"type":109,"tag":421,"props":606,"children":608},{"style":607},"--shiki-default:#85E89D",[609],{"type":118,"value":610},"repos",{"type":109,"tag":421,"props":612,"children":614},{"style":613},"--shiki-default:#E1E4E8",[615],{"type":118,"value":616},":\n",{"type":109,"tag":421,"props":618,"children":619},{"class":423,"line":442},[620,625],{"type":109,"tag":421,"props":621,"children":622},{"style":607},[623],{"type":118,"value":624},"  poky",{"type":109,"tag":421,"props":626,"children":627},{"style":613},[628],{"type":118,"value":616},{"type":109,"tag":421,"props":630,"children":632},{"class":423,"line":631},4,[633,638,643],{"type":109,"tag":421,"props":634,"children":635},{"style":607},[636],{"type":118,"value":637},"    url",{"type":109,"tag":421,"props":639,"children":640},{"style":613},[641],{"type":118,"value":642},": ",{"type":109,"tag":421,"props":644,"children":646},{"style":645},"--shiki-default:#9ECBFF",[647],{"type":118,"value":648},"\"https://git.yoctoproject.org/poky\"\n",{"type":109,"tag":421,"props":650,"children":652},{"class":423,"line":651},5,[653,658,662],{"type":109,"tag":421,"props":654,"children":655},{"style":607},[656],{"type":118,"value":657},"    refspec",{"type":109,"tag":421,"props":659,"children":660},{"style":613},[661],{"type":118,"value":642},{"type":109,"tag":421,"props":663,"children":664},{"style":645},[665],{"type":118,"value":666},"\"scarthgap-5.0.5\"\n",{"type":109,"tag":421,"props":668,"children":670},{"class":423,"line":669},6,[671,676],{"type":109,"tag":421,"props":672,"children":673},{"style":607},[674],{"type":118,"value":675},"  meta-openembedded",{"type":109,"tag":421,"props":677,"children":678},{"style":613},[679],{"type":118,"value":616},{"type":109,"tag":421,"props":681,"children":683},{"class":423,"line":682},7,[684,688,692],{"type":109,"tag":421,"props":685,"children":686},{"style":607},[687],{"type":118,"value":637},{"type":109,"tag":421,"props":689,"children":690},{"style":613},[691],{"type":118,"value":642},{"type":109,"tag":421,"props":693,"children":694},{"style":645},[695],{"type":118,"value":696},"\"https://git.openembedded.org/meta-openembedded\"\n",{"type":109,"tag":421,"props":698,"children":700},{"class":423,"line":699},8,[701,705,709],{"type":109,"tag":421,"props":702,"children":703},{"style":607},[704],{"type":118,"value":657},{"type":109,"tag":421,"props":706,"children":707},{"style":613},[708],{"type":118,"value":642},{"type":109,"tag":421,"props":710,"children":711},{"style":645},[712],{"type":118,"value":713},"\"scarthgap\"\n",{"type":109,"tag":114,"props":715,"children":716},{},[717,719,725],{"type":118,"value":718},"Never point at ",{"type":109,"tag":160,"props":720,"children":722},{"className":721},[],[723],{"type":118,"value":724},"HEAD",{"type":118,"value":726}," of a branch for production builds. A layer maintainer can push a breaking change at any time, and your next build produces a different image.",{"type":109,"tag":148,"props":728,"children":730},{"id":729},"upgrade-strategy",[731],{"type":118,"value":732},"Upgrade strategy",{"type":109,"tag":114,"props":734,"children":735},{},[736],{"type":118,"value":737},"When upgrading between Yocto releases (e.g., Scarthgap → Walnascar):",{"type":109,"tag":194,"props":739,"children":741},{"id":740},"_1-read-the-migration-guide",[742],{"type":118,"value":743},"1. Read the migration guide",{"type":109,"tag":114,"props":745,"children":746},{},[747],{"type":118,"value":748},"Every Yocto release includes a migration guide documenting breaking changes. Read it completely before starting.",{"type":109,"tag":194,"props":750,"children":752},{"id":751},"_2-update-layers-sequentially",[753],{"type":118,"value":754},"2. Update layers sequentially",{"type":109,"tag":114,"props":756,"children":757},{},[758,760,765,767,772],{"type":118,"value":759},"Update ",{"type":109,"tag":160,"props":761,"children":763},{"className":762},[],[764],{"type":118,"value":214},{"type":118,"value":766}," first, then ",{"type":109,"tag":160,"props":768,"children":770},{"className":769},[],[771],{"type":118,"value":232},{"type":118,"value":773},", then vendor BSP layers, then your product layers. Fix breakage at each stage before proceeding.",{"type":109,"tag":194,"props":775,"children":777},{"id":776},"_3-handle-recipe-version-bumps",[778],{"type":118,"value":779},"3. Handle recipe version bumps",{"type":109,"tag":114,"props":781,"children":782},{},[783,785,791,793,798],{"type":118,"value":784},"Run ",{"type":109,"tag":160,"props":786,"children":788},{"className":787},[],[789],{"type":118,"value":790},"bitbake-layers show-appends",{"type":118,"value":792}," to find ",{"type":109,"tag":160,"props":794,"children":796},{"className":795},[],[797],{"type":118,"value":242},{"type":118,"value":799}," files that no longer match their base recipes. Fix or remove them.",{"type":109,"tag":194,"props":801,"children":803},{"id":802},"_4-test-incrementally",[804],{"type":118,"value":805},"4. Test incrementally",{"type":109,"tag":114,"props":807,"children":808},{},[809],{"type":118,"value":810},"Build a minimal image first. Once that works, add your product packages one at a time. This isolates which package's recipe needs updating.",{"type":109,"tag":194,"props":812,"children":814},{"id":813},"_5-budget-time-realistically",[815],{"type":118,"value":816},"5. Budget time realistically",{"type":109,"tag":114,"props":818,"children":819},{},[820],{"type":118,"value":821},"A major Yocto version upgrade for a complex product typically takes 2-4 weeks of engineering time. Plan it as a first-class project milestone, not a Friday afternoon task. The Yocto 5.2 Walnascar release notes covers the most relevant changes for embedded teams.",{"type":109,"tag":148,"props":823,"children":825},{"id":824},"layer-anti-patterns-that-cause-upgrade-pain",[826],{"type":118,"value":827},"Layer anti-patterns that cause upgrade pain",{"type":109,"tag":114,"props":829,"children":830},{},[831,833,838],{"type":118,"value":832},"Putting everything in one layer is the most common mistake. BSP recipes, distro configuration, application packages, and image recipes all in ",{"type":109,"tag":160,"props":834,"children":836},{"className":835},[],[837],{"type":118,"value":268},{"type":118,"value":839}," makes it impossible to share application recipes across boards or products without carrying irrelevant BSP code along with them.",{"type":109,"tag":114,"props":841,"children":842},{},[843,845,850,852,857],{"type":118,"value":844},"Copying entire recipes from community layers into your product layer instead of using ",{"type":109,"tag":160,"props":846,"children":848},{"className":847},[],[849],{"type":118,"value":242},{"type":118,"value":851}," is the other big one. It looks like a shortcut at the time - you own the recipe, you can change it freely - but you have now opted out of upstream improvements and security fixes. Every time ",{"type":109,"tag":160,"props":853,"children":855},{"className":854},[],[856],{"type":118,"value":232},{"type":118,"value":858}," patches a CVE in that recipe, you will not get it.",{"type":109,"tag":114,"props":860,"children":861},{},[862,864,869],{"type":118,"value":863},"Layers without a README, no documented dependencies, and no explanation of what they provide are a constant source of friction. The next engineer joining the project should not have to reverse-engineer your layer graph from ",{"type":109,"tag":160,"props":865,"children":867},{"className":866},[],[868],{"type":118,"value":165},{"type":118,"value":870},".",{"type":109,"tag":114,"props":872,"children":873},{},[874],{"type":118,"value":875},"Finally, unversioned layers - no tags, no branches aligned to Yocto releases - make it impossible to answer the question \"which Yocto version is this layer compatible with?\" That question comes up every time someone needs to reproduce an old build or evaluate an upgrade path.",{"type":109,"tag":148,"props":877,"children":879},{"id":878},"integration-with-proteanos",[880],{"type":118,"value":881},"Integration with ProteanOS",{"type":109,"tag":114,"props":883,"children":884},{},[885,887,894,896,902,904,910],{"type":118,"value":886},"ProteanOS's ",{"type":109,"tag":888,"props":889,"children":891},"a",{"href":890},"/dev/pkg/spf-2.0/",[892],{"type":118,"value":893},"packaging system",{"type":118,"value":895}," generates recipe-compatible metadata that can be consumed by Yocto layers. The ",{"type":109,"tag":888,"props":897,"children":899},{"href":898},"/dev/prokit/",[900],{"type":118,"value":901},"ProKit",{"type":118,"value":903}," build tools can generate ",{"type":109,"tag":160,"props":905,"children":907},{"className":906},[],[908],{"type":118,"value":909},".bb",{"type":118,"value":911}," recipe files from ProteanOS package control files, simplifying integration between the two ecosystems.",{"type":109,"tag":114,"props":913,"children":914},{},[915],{"type":118,"value":916},"Build your layer stack with the assumption that someone else will maintain it in two years - which, practically speaking, might still be you after a long enough gap.",{"type":109,"tag":114,"props":918,"children":919},{},[920],{"type":118,"value":921},"For teams using the Yocto eSDK, layer structure determines what is available in the SDK. Well-structured layers produce clean, usable SDKs.",{"type":109,"tag":148,"props":923,"children":925},{"id":924},"the-return-on-layer-discipline",[926],{"type":118,"value":927},"The return on layer discipline",{"type":109,"tag":114,"props":929,"children":930},{},[931,933,938],{"type":118,"value":932},"Yocto layers that stay maintainable follow clear principles: one concern per layer, explicit priorities, minimal ",{"type":109,"tag":160,"props":934,"children":936},{"className":935},[],[937],{"type":118,"value":242},{"type":118,"value":939}," usage, pinned versions, and documented upgrade procedures. The investment in getting this right upfront pays off with every subsequent release upgrade. The teams that treat layer structure as an afterthought are the ones spending three weeks on Yocto upgrades that should take three days.",{"type":109,"tag":941,"props":942,"children":943},"style",{},[944],{"type":118,"value":945},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}",{"title":104,"searchDepth":433,"depth":433,"links":947},[948,949,952,953,954,957,958,965,966,967],{"id":150,"depth":433,"text":153},{"id":175,"depth":433,"text":178,"children":950},[951],{"id":196,"depth":442,"text":199},{"id":291,"depth":433,"text":294},{"id":387,"depth":433,"text":390},{"id":456,"depth":433,"text":459,"children":955},[956],{"id":511,"depth":442,"text":514},{"id":559,"depth":433,"text":562},{"id":729,"depth":433,"text":732,"children":959},[960,961,962,963,964],{"id":740,"depth":442,"text":743},{"id":751,"depth":442,"text":754},{"id":776,"depth":442,"text":779},{"id":802,"depth":442,"text":805},{"id":813,"depth":442,"text":816},{"id":824,"depth":433,"text":827},{"id":878,"depth":433,"text":881},{"id":924,"depth":433,"text":927},"markdown","content:dev:yocto-layers-maintainable-strategy-2026.md","content","dev/yocto-layers-maintainable-strategy-2026.md","dev/yocto-layers-maintainable-strategy-2026","md",1791796266099]