Yocto project does all of its testing in qemu (which needs only the kernel file and .ext4 rootfs file to be given to qemu executable as command line options). Yocto also does not endorse any particular flashing tool, or an OTA update solution, and will not pick a favorite.
On the other hand such a reference implementation for end-to-end full hardware product bundle must be testable and tested. We simply don't have resources to do it. One conceivably could implement a soft set of guidelines and add them to YP compatible layer certification program, but again such a project is outside of our stretched-beyond-thin resources. Talk to your vendors instead and see if you can make them cooperate. Alex On Thu, 23 Jan 2025 at 09:01, Oliver Westermann via lists.yoctoproject.org <oliver.westermann=cognex....@lists.yoctoproject.org> wrote: > > Hey, > > When we're building a full software setup for a certain embedded architecture > to completly setup a device, that contains various components which are > collected in some "post-rootfs-packaging" > > * A rootfs > * Kernel > * Bootloaders > * Firmware > * potentially setup components not ending up on the final device state > (initramfs for USB bootstrap for example) > * tooling for USB/flasher/etc (eg ADB) > > Those to bootstrap a device (e.g. via USB/flasher/...), something therefore > collects the output of various recipes, both images (rootfs) and non-images > (bootloader files, firmware, ...) and packages them in a custom way. Often > this includs additional tooling, like flashing tools or install scripting. > Working with various SoC vendors, I've seen various setups, and I'm not sure > if there is any guidance on whats correct > > * Some vendors have external tooling. This tooling expects the right files in > the right place (eg. deploy dir) to bootstrap a device > * Some vendors integrate this into yocto, having a custom recipe that depends > on recipes and packages the output > * Some meta-layers for OTA update do something similar, inherit the image > type, but disable most image tasks and don't actually build an "image" (e.g. > swupdate) > * Some vendors implement custom image types > > When trying to support multiple SoC/BSP vendors, this sometimes leads to > conflicts and questions, but I was unable to find some references to this in > the yocto documentation. A custom image type feels most integrated into > yocto, but I've seen some "hacks" in there that make me question if this is > intended? Is there anything like a reference implementation for > "post-rootfs-packaging"? > > Best regards, Olli > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#64618): https://lists.yoctoproject.org/g/yocto/message/64618 Mute This Topic: https://lists.yoctoproject.org/mt/110768646/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
