Problems with BIF Attribute [bootimage]

[cubex108]

The [bootimage] attribute seems to modify the state of the original partition in the input image, especially the partition with the [offset] attribute specified.

The test process is as follows：

1. I used the following bif file to generate an image called BASE_BOOT.BIN

the_loader_image:  
{                                         
	[bootloader] ./images/linux/zynq_fsbl.elf
	./images/linux/system.bit
	./images/linux/u-boot.elf
	[load=0x00100000] ./images/linux/system.dtb
	[offset=0x440000, partition_owner=uboot] ./images/linux/boot.scr
} 

2.Then I used the following bif file to generate another image called RE_BASE_BOOT.BIN

the_ROM_image:
{
    [bootimage] ./images/linux/BASE_BOOT.BIN
}

3.BASE_BOOT.BIN and RE_BASE_BOOT.BIN are not the same size, so I compared the binary content of the two files. I found that the address of the ./images/linux/boot.scr partition has changed， Its starting address becomes the address immediately following the ./images/linux/system.dtb partition，In other words, the [offset] attribute of the ./images/linux/boot.scr partition is invalid

I don’t know if this is a bug, and I want to know how to avoid this problem: do not modify the original state of the input partition when using the [bootimage] attribute

[RamyaDarapuneni]

Hi @cubex108
Ideally this is never supported, so I am not sure if we should call this a bug.
But for my understanding, Can you please explain the use case you are trying this for?

Thanks
Ramya Darapuneni

[jcatsong]

Resurrecting a very old issue.

@RamyaDarapuneni can you provide the expected use case for the [bootimage] attribute? I don't know what @cubex108's original use case was, but I was investigating if this could be used to take a pre-existing .bin file and re-generate dual_qspi_mode files.