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

Hi Arnout,

On 7/30/26 6:25 PM, Arnout Vandecappelle wrote:
>   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.

We'll be sharing everything but the bootloader and device tree.

If it's the expected approach then I will set it up this way.
Since we're sharing the userspace, kernel, and so on, fully, I'm 
thinking I should just have defconfigs for each bootloader build and 
another defconfig for the rest, and just combine everything in post.

Thanks for the feedback!

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