Re: [Buildroot] Correct approach for supporting multiple SoCs with otherwise same board?

  Hi John,


On 13/07/2026 10:17, John Ernberg via buildroot wrote:
> Hi,
> 
> We have a board with a few different iMX8X series SoCs,
> which we have worked around by having a custom imx-seco package that
> installs the different AHAB containers we need.
> 
> Now we're introducing a new SoC onto this board that is not compatible
> with the iMX8X. However, Linux and userspace will be the same for all
> boards as they need to be interchangeable with each other.
> 
> The only things we need to generate differently now is the bootloader
> and ATF.
> 
> The bootflow is bootloader -> ATF -> Linux
> 
> What is the correct way to handle this?
> Should we separate the firmwares + bootloader + ATF configs from
> the Linux + userspace build config?

  Assuming you don't want to try to generate a single userspace image for both 
boards, the best approach is to create a separate config for each board type. If 
you want to make it explicit that it's mostly the same, you can split that 
config into a "boot" part and a "userspace" part, where the same userspace part 
is used for both. You simply add a Makefile or other script (to your external, I 
presume) that concatenates them and then calls `make defconfig DEFCONFIG=...` 
pointing to the generated file.

  Note that there's also a script, support/kconfig/merge_config.sh. It checks 
for conflicting options, but it's far from foolproof. `cat` mostly works as well.

  The annoying part of a split config is that you can't easily change it with 
menuconfig followed by savedefconfig. After the savedefconfig, you have to 
extract the changed part. There is a script utils/diffconfig that can help, but 
it's probably best to manually apply the changes to the original split 
configurations.


> Separation feels odd though as that means we need to let the
> post-image.sh script we have for producing boot images (ATF + Linux +
> DTBs)  wander into other build directories.
  OK, this does sound like the idea is to reuse the same userspace image for 
both. For me, it doesn't sound weird at all to look for images in other build 
directories. For example, I typically have a separate config for generating a 
custom toolchain that can be built as an external toolchain. I put all the build 
directories in a fixed place under the external, so I can refer to the external 
toolchain as $(BR2_EXTERNAL_..._PATH)/output/host/bin/gcc.

  Regards,
  Arnout

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot