Skip to content

GitLab

Switch branch/tag
  1. 14 Jan, 2017 2 commits
    • Masahiro Yamada's avatar
      fiptool: fix add_image() and add_image_desc() implementation · 11c0a4ff
      Masahiro Yamada authored 
      The "make fip" shows the content of the generated FIP at the end of
the build.  (This is shown by "fiptool info" command.)

Prior to commit e0f083a0 ("fiptool: Prepare ground for expanding
the set of images at runtime"), the last part of the build log of
 make CROSS_COMPILE=aarch64-linux-gnu- BL33=../u-boot/u-boot.bin fip
was like follows:

 Trusted Boot Firmware BL2: offset=0xB0, size=0x4188, cmdline="--tb-fw"
 EL3 Runtime Firmware BL31: offset=0x4238, size=0x6090, cmdline="--soc-fw"
 Non-Trusted Firmware BL33: offset=0xA2C8, size=0x58B51, cmdline="--nt-fw"

With that commit, now it is displayed like follows:

 Non-Trusted Firmware BL33: offset=0xB0, size=0x58B51, cmdline="--nt-fw"
 EL3 Runtime Firmware BL31: offset=0x58C01, size=0x6090, cmdline="--soc-fw"
 Trusted Boot Firmware BL2: offset=0x5EC91, size=0x4188, cmdline="--tb-fw"

You will notice two differences:
  - the contents are displayed in BL33, BL31, BL2 order
  - the offset values are wrong

The latter is more serious, and means "fiptool info" is broken.

Another interesting change is "fiptool update" every time reverses
the image order.  For example, if you input FIP with BL2, BL31, BL33
in this order, the command will pack BL33, BL31, BL2 into FIP, in
this order.  Of course, the order of components is not a big deal
except that users will have poor impression about this.

The root cause is in the implementation of add_image(); the
image_head points to the last added image.  For example, if you call
add_image() for BL2, BL31, BL33 in this order, the resulted image
chain is:

  image_head -> BL33 -> BL31 -> BL2

Then, they are processed from the image_head in "for" loops:

  for (image = image_head; image != NULL; image = image->next) {

This means images are handled in Last-In First-Out manner.

Interestingly, "fiptool create" is still correct because
add_image_desc() also reverses the descriptor order and the command
works as before due to the double reverse.

The implementation of add_image() is efficient, but it made the
situation too complicated.

Let's make image_head point to the first added image.  This will
add_image() inefficient because every call of add_image() follows
the ->next chain to get the tail.  We can solve it by adopting a
nicer linked list structure, but I am not doing as far as that
because we handle only limited number of images anyway.

Do likewise for add_image_desc().

Fixes: e0f083a0

 ("fiptool: Prepare ground for expanding the set of images at runtime")
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      11c0a4ff
    • Masahiro Yamada's avatar
      fiptool: introduce xzalloc() helper function · 696ccba6
      Masahiro Yamada authored 
      
We often want to zero out allocated memory.

My main motivation for this commit is to set image::next and
image_desc::next to NULL automatically in the next commit.
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      696ccba6
  3. 13 Jan, 2017 2 commits
  5. 11 Jan, 2017 1 commit
  7. 10 Jan, 2017 4 commits
  9. 06 Jan, 2017 2 commits
  11. 05 Jan, 2017 4 commits
  13. 04 Jan, 2017 1 commit
  15. 30 Dec, 2016 5 commits
  17. 23 Dec, 2016 2 commits
    • davidcunado-arm's avatar
      Merge pull request #798 from douglas-raillard-arm/dr/fix_std_smc_after_suspend · cef7b3ce
      davidcunado-arm authored 
      Abort preempted TSP STD SMC after PSCI CPU suspend
      cef7b3ce
    • Douglas Raillard's avatar
      Abort preempted TSP STD SMC after PSCI CPU suspend · 3df6012a
      Douglas Raillard authored 
      Standard SMC requests that are handled in the secure-world by the Secure
Payload can be preempted by interrupts that must be handled in the
normal world. When the TSP is preempted the secure context is stored and
control is passed to the normal world to handle the non-secure
interrupt. Once completed the preempted secure context is restored. When
restoring the preempted context, the dispatcher assumes that the TSP
preempted context is still stored as the SECURE context by the context
management library.

However, PSCI power management operations causes synchronous entry into
TSP. This overwrites the preempted SECURE context in the context
management library. When restoring back the SECURE context, the Secure
Payload crashes because this context is not the preempted context
anymore.

This patch avoids corruption of the preempted SECURE context by aborting
any preempted SMC during PSCI power management calls. The
abort_std_smc_entry hook of the TSP is calle...
      3df6012a
  19. 21 Dec, 2016 1 commit
  21. 20 Dec, 2016 14 commits
  23. 19 Dec, 2016 2 commits