fiptool: revive replace_image() to keep the image order by update command

Commit e0f083a09b ("fiptool: Prepare ground for expanding the set
of images at runtime") introduced another side effect; the "update"
command now changes the image order in the FIP.

Let's say you have an FIP with BL2, BL31, BL32, BL33.  If you update
for example, BL32 with the "update" command, you will get a new FIP
with BL2, BL31, BL33, BL32, in this order.

It happens like this; remove_image() removes the old image from the
linked list, add_image() adds the new image at the tail of the list,
then images are packed in the new order.  Prior to that commit,
images were updated by replace_image(), but it was deleted by the
re-work.  Revive replace_image() that is re-implemented to work with
the linked list.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This commit is contained in:
Masahiro Yamada 2017-01-27 11:57:54 +09:00
parent 67973fb4f7
commit ea39d557ae
1 changed files with 17 additions and 2 deletions

View File

@ -254,6 +254,22 @@ static void add_image(image_t *image)
nr_images++;
}
static void replace_image(image_t *image)
{
image_t **p = &image_head;
while (*p) {
if (!memcmp(&(*p)->uuid, &image->uuid, sizeof(image->uuid)))
break;
p = &(*p)->next;
}
assert(*p != NULL);
image->next = (*p)->next;
*p = image;
}
static void free_image(image_t *image)
{
free(image->buffer);
@ -673,8 +689,7 @@ static void update_fip(void)
desc->cmdline_name,
desc->action_arg);
}
remove_image(old_image);
add_image(new_image);
replace_image(new_image);
} else {
if (verbose)
log_dbgx("Adding image %s",