[PATCH V7 01/15] board: siemens: iot2050: Split the build for PG1 and PG2

Jan Kiszka jan.kiszka at siemens.com
Wed Mar 1 20:21:58 CET 2023

On 01.03.23 19:34, Andrew Davis wrote:
> On 3/1/23 12:29 PM, Jan Kiszka wrote:
>> On 01.03.23 18:26, Andrew Davis wrote:
>>> On 2/28/23 12:19 PM, Jan Kiszka wrote:
>>>> From: Su Baocheng <baocheng.su at siemens.com>
>>>> Due to different signature keys, the PG1 and the PG2 boards can no
>>>> longer use the same FSBL (tiboot3). This makes it impossible anyway to
>>>> maintaine a single flash.bin for both variants, so we can also split
>>>> the
>>>> build.
>>> Having two defconfigs just to make the small changes needed will be
>>> more burden than it saves. Keeping them in sync and having your
>>> integration
>>> layer do two different builds just adds more work than it is worth IMHO.
>>> We (TI) are going in that direction for our HS boards and combining the
>>> defconfigs back together now. The solution is to have the one defconfig
>>> build both images, one for HS and one for non-HS. For you looks like you
>>> are already calling the two PG boot images differently so this should
>>> work
>>> (seboot_pg1.bin and seboot_pg2.bin). Just add a new full entry in
>>> boot-image.dtsi for each (vs that #ifdef check changing the output
>>> name).
>> How should that work? Will we somehow get two flash.bin out of a single
>> build then?
> Yes if you add two enteries in your image.dtsi file. Then your integration
> selects the right named one for the board, instead of selecting the right
> defconfig for the board and doing a completely new build.

Something like this?

binman: binman {

&binman {
	flash-pg1 {
		filename = "flash-pg1.bin"

	flash-pg2 {
		filename = "flash-pg2.bin"

How to avoid duplicating the common nodes of flash-pg1/pg2?


Siemens AG, Technology
Competence Center Embedded Linux

More information about the U-Boot mailing list