On 11-07-2024 15:23, philip.dawson via lists.yoctoproject.org wrote:
Hi,
I asked a similar question over in @yocto and got pointed in this direction.
(https://lists.yoctoproject.org/g/yocto/topic/common_kernel_and_rootfs/107140139
<https://lists.yoctoproject.org/g/yocto/topic/common_kernel_and_rootfs/107140139>)
We have multiple products we build images for through Petalinux. Each product
has it's own Petalinux project and BSP. The created rootfs images are almost
identical (and we could probably the contents the same if we knew it was worth
trying).
Because each product has its own device tree which is a dependency of the
kernel build we end up with having to rebuild the kernel for each product even
if we point them to the same sstate-cache.
This effect propagates through the kernel-modules and our custom drivers to
our software stack (via driver headers for ioctls). So we end up building a
lot of the same code many times over for any given change.
Yeah, that's a quirk of petalinux mostly. Even building the same thing for the
same machine often triggers builds for kernel and bootloader and whatnot.
Petalinux has this "one project one machine one image" build flow that's
almost impossible to get around.
With Yocto builds these effects can be drastically reduced.
I'm trying to reduce time spent in CI builds and reduce disk usage of our
final images (having multiple almost identical rootfs images takes up a lot of
room).
Is there any way through Petalinux (or standard yocto) we could somehow have a
common build of the kernel and rootfs but still split/package/tweak this to
generate multiple images each with a different bootloader and device tree?
What we do is build only the FSBL using the XSA, and just build the rest (e.g.
devicetree) "by hand".
If boards are similar, we often create an XSA that just contains enough to
boot the board(s), so that they all share the same XSA, even though they might
be totally different chips (e.g. a zu6, zu9 and zu15 can share the same boot.bin)
Then we use our own recipe to fetch FPGA bitstreams and PL devicetree
overlays. We always program the PL from Linux by the way.
This breaks the big dependency spaghetti that starts at the XSA and expands
throughout the tree. Thus, after changing the XSA the kernel won't rebuild.
The PS GT lane setup is done by FSBL code, which is the biggest concern in
sharing boot code amongst boards. If the PS GT initialization could be
completely done from the kernel, way more sharing would be possible. This is
especially important for upgrades in the field, as it reduces chances of ever
needing to upgrade the bootloader.
I appreciate this might not be possible, but thought it was at least worth
asking.
Best Regards,
Phil Dawson
--
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: [email protected]
W: www.topic.nl
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5454):
https://lists.yoctoproject.org/g/meta-xilinx/message/5454
Mute This Topic: https://lists.yoctoproject.org/mt/107162406/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
