Skip to content

GitLab

Switch branch/tag
  1. 24 Jul, 2019 5 commits
    • Julius Werner's avatar
      plat/mediatek/mt81*: Use new bl31_params_parse() helper · cbdc72b5
      Julius Werner authored 
      

The Mediatek MT8173/MT8183 SoCs are prime candidates for switching to
the new bl31_params_parse() helper, so switch them over. This will allow
BL2 implementations on these platforms to transparently switch over to
the version 2 parameter structure.

Change-Id: I0d17ba6c455102d325a06503d2078a76d12b5deb
Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      cbdc72b5
    • Julius Werner's avatar
      plat/rockchip: Use new bl31_params_parse_helper() · 3e02c743
      Julius Werner authored 
      

The Rockchip platform is a prime candidate for switching to the new
bl31_params_parse_helper(), so switch it over. This will allow BL2
implementations on this platform to transparently switch over to the
version 2 parameter structure.

Change-Id: I540741d2425c93f66c8697ce749a351eb2b3a7e8
Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      3e02c743
    • Julius Werner's avatar
      Factor out cross-BL API into export headers suitable for 3rd party code · 57bf6057
      Julius Werner authored 
      

This patch adds a new include/export/ directory meant for inclusion in
third-party code. This is useful for cases where third-party code needs
to interact with TF-A interfaces and data structures (such as a custom
BL2-implementation like coreboot handing off to BL31). Directly
including headers from the TF-A repository avoids having to duplicate
all these definitions (and risk them going stale), but with the current
header structure this is not possible because handoff API definitions
are too deeply intertwined with other TF code/headers and chain-include
other headers that will not be available in the other environment.

The new approach aims to solve this by separating only the parts that
are really needed into these special headers that are self-contained and
will not chain-include other (non-export) headers. TF-A code should
never include them directly but should instead always include the
respective wrapper header, which will include the required prerequisites
(like <stdint.h>) before including the export header. Third-party code
can include the export headers via its own wrappers that make sure the
necessary definitions are available in whatever way that environment can
provide them.

Change-Id: Ifd769320ba51371439a8e5dd5b79c2516c3b43ab
Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      57bf6057
    • Julius Werner's avatar
      Use explicit-width data types in AAPCS parameter structs · 9352be88
      Julius Werner authored 
      

It's not a good idea to use u_register_t for the members of
aapcs64_params_t and aapcs32_params_t, since the width of that type
always depends on the current execution environment. This would cause
problems if e.g. we used this structure to set up the entry point of an
AArch32 program from within an AArch64 program. (It doesn't seem like
any code is doing that today, but it's probably still a good idea to
write this defensively. Also, it helps with my next patch.)

Change-Id: I12c04a85611f2b6702589f3362bea3e6a7c9f776
Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      9352be88
    • Julius Werner's avatar
      plat/rockchip: Switch to use new common BL aux parameter library · c1185ffd
      Julius Werner authored 
      

This patch changes all Rockchip platforms to use the new common BL aux
parameter helpers. Since the parameter space is now cleanly split in
generic and vendor-specific parameters and the COREBOOT_TABLE
parameter is now generic, the parameter type number for that parameter
has to change. Since it only affects coreboot which always builds TF as
a submodule and includes its headers directly to get these constants,
this should not cause any issues. In general, after this point, we
should avoid changing already assigned parameter type numbers whenever
possible.

Change-Id: Ic99ddd1e91ff5e5fe212fa30c793a0b8394c9dad
Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      c1185ffd
  3. 12 Jul, 2019 5 commits
  5. 11 Jul, 2019 5 commits
  7. 10 Jul, 2019 2 commits
  9. 08 Jul, 2019 1 commit
  11. 05 Jul, 2019 1 commit
    • Masahiro Yamada's avatar
      uniphier: support console based on multi-console · ac9f1b55
      Masahiro Yamada authored 
      

The legacy console is gone. Re-add the console support based on the
multi-console framework.

I am still keeping the putc, getc, and flush callbacks in
uniphier_console.S to use plat/common/aarch64/crash_console_helpers.S

The console registration code already relies on that C environment
has been set up. So, I just filled the struct console fields with the
callback pointers, then called console_register() directly. I also
re-implemented the init function in C to improve the readability.

Removing the custom crash console implementation has one disadvantage;
we cannot use the crash console on very early crashes because
crash_console_helpers.S works only after the console is registered.
I can live with this limitation.

Tested on my boards, and confirmed this worked like before.

Change-Id: Ieab9c849853ff6c525c15ea894a85944f257db59
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      ac9f1b55
  13. 04 Jul, 2019 2 commits
  15. 01 Jul, 2019 2 commits
  17. 28 Jun, 2019 3 commits
  19. 26 Jun, 2019 5 commits
  21. 22 Jun, 2019 1 commit
  23. 20 Jun, 2019 2 commits
  25. 17 Jun, 2019 6 commits