refactor(build): avoid implicit pattern rules

This change translates any implicit pattern rules into the equivalent
static pattern rules, i.e. rules like:

%.o: %.s
...

... become:

refactor(build): avoid implicit pattern rules

This change translates any implicit pattern rules into the equivalent
static pattern rules, i.e. rules like:

%.o: %.s
...

... become:

$(OBJS): %.o: %.s
...

These behave similarly, but have some subtle differences. The former
defines a rule "for any target matching %.o where there is not a more
specific rule", whereas the latter defines a rule "for these targets,
which match %.o".

Where possible it is better to use a static pattern rule as it reduces
the rule space that Make needs to search.

Change-Id: Ifba4f44bcecf4e74980c31347e192cdf1e42003e
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

fix(sptool): handle load-address-relative-offset property

If the SP manifest contains load-address-relative-offset then the script
failed to generate the sp_list_fragment.dts file because that line

fix(sptool): handle load-address-relative-offset property

If the SP manifest contains load-address-relative-offset then the script
failed to generate the sp_list_fragment.dts file because that line was
also added to the load_address_lines list.
This commit fixes this issue: a line is only added to the list if the
property name is exactly "load-address", without a following '-'
character.

Change-Id: I1fd2006d37d9cc1864af31576e60565a7bce6023
Signed-off-by: Bence Balogh <bence.balogh@arm.com>

show more ...

feat(sptool): add StMM memory region descriptor

StandaloneMM partition requires that the first memory region in its list
of reserved memory regions describe the full partition layout. Hafnium
SPMC c

feat(sptool): add StMM memory region descriptor

StandaloneMM partition requires that the first memory region in its list
of reserved memory regions describe the full partition layout. Hafnium
SPMC checks that memory regions in FF-A manifest do not overlap.
Therefore, this region is added directly in HOB generation code rather
than as a memory region in the FF-A manifest for the StMM partition.

Signed-off-by: Kathleen Capella <kathleen.capella@arm.com>
Change-Id: Ia22174d755a5776e20ecf9639584f3c08cf9e60e

show more ...

feat(sptool): specify endianness for HOB bin

Specify endianness encoding when packing HOB binary. Little-endian is
used as target platforms are expected to be little-endian.

Signed-off-by: Kathleen

feat(sptool): specify endianness for HOB bin

Specify endianness encoding when packing HOB binary. Little-endian is
used as target platforms are expected to be little-endian.

Signed-off-by: Kathleen Capella <kathleen.capella@arm.com>
Change-Id: I28d7b302f79482ed142c1964409c310f713a9b8c

show more ...

feat(sptool): include HOB file in the TL pkg

If the "hob_path" has been introduced in the `args`
dictionary, use it when creating a Transfer List
type of package.

Create a HOB entry in the transfer

feat(sptool): include HOB file in the TL pkg

If the "hob_path" has been introduced in the `args`
dictionary, use it when creating a Transfer List
type of package.

Create a HOB entry in the transfer list with the
respective transfer entry type.

Signed-off-by: Kathleen Capella <kathleen.capella@arm.com>
Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: Ie5fefe90205cf89ee26c3683048bf42229cb4bee

show more ...

feat(sptool): invoke the HOB list creation code

Add an SP setup function that invokes the HOB creation
utilities.

It introduces an argument "hob_path" to the shared dictionary of args
with the loca

feat(sptool): invoke the HOB list creation code

Add an SP setup function that invokes the HOB creation
utilities.

It introduces an argument "hob_path" to the shared dictionary of args
with the location of the generated binary containing the HOB list.

Signed-off-by: Kathleen Capella <kathleen.capella@arm.com>
Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: I26a07027b6344c9d7ba732d022932736a62e2505

show more ...

feat(sptool): add the HOB list creation script

Add python library to build the Handoff Block list (HOB list) for an SP
at build time.

Signed-off-by: Kathleen Capella <kathleen.capella@arm.com>
Chan

feat(sptool): add the HOB list creation script

Add python library to build the Handoff Block list (HOB list) for an SP
at build time.

Signed-off-by: Kathleen Capella <kathleen.capella@arm.com>
Change-Id: I17d46f7ed21ce42a83f33dfdc4fad038653d1ec3

show more ...

Merge "feat(sptool): transfer list to replace SP Pkg" into integration

feat(sptool): transfer list to replace SP Pkg

Generate the rules for calling 'tlc' tool, and generating
a partition package as a TL:
- The data is aligned to 4k.
- Using TE types 0x103 for FF-A mani

feat(sptool): transfer list to replace SP Pkg

Generate the rules for calling 'tlc' tool, and generating
a partition package as a TL:
- The data is aligned to 4k.
- Using TE types 0x103 for FF-A manifest, and 0x106 for
FF-A SP binary.

Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: I1941e3e8f43d8dad33cdd0dea0571cf4a0d5e8f3

show more ...

feat(sptool): populate secure partition number in makefile

Calculate the secure partition number and saves it into the defined
macro NUM_SP.

Signed-off-by: Ben Horgan <ben.horgan@arm.com>
Signed-of

feat(sptool): populate secure partition number in makefile

Calculate the secure partition number and saves it into the defined
macro NUM_SP.

Signed-off-by: Ben Horgan <ben.horgan@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>
Change-Id: I4175a10d315482b65fd0f3eed4c6fd1e1e2b5e4d

show more ...

build: remove Windows compatibility layer

For a couple of releases now we have officially withdrawn support for
building TF-A on Windows using the native environment, relying instead
on POSIX emulat

build: remove Windows compatibility layer

For a couple of releases now we have officially withdrawn support for
building TF-A on Windows using the native environment, relying instead
on POSIX emulation layers like MSYS2, Mingw64, Cygwin or WSL.

This change removes the remainder of the OS compatibility layer
entirely, and migrates the build system over to explicitly relying on a
POSIX environment.

Change-Id: I8fb60d998162422e958009afd17eab826e3bc39b
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

build: determine toolchain tools dynamically

Since the introduction of the toolchain detection framework into the
build system, we have done determination and identification of the
toolchain(s) used

build: determine toolchain tools dynamically

Since the introduction of the toolchain detection framework into the
build system, we have done determination and identification of the
toolchain(s) used for the build at the initialization of the build
system.

This incurs a large cost to the build every time - for every toolchain
that has been requested by the current makefile, we try to identify each
tool in the list of known tool classes, even if that tool doesn't
actually see any use.

For the clean and check-like targets we worked around this by disabling
most of the toolchains if we detect these targets, but this is
inflexible and not very reliable, and it still means that when building
normal targets we are incurring that cost for all tools whether they are
used or not.

This change instead modifies the toolchain detection framework to only
initialize a tool for a given toolchain when it is first used. This does
mean that we can no longer warn about an incorrectly-configured
toolchain at the beginning of build system invocation, but it has the
advantage of substantially reducing build time and the complexity of
*using* the framework (at the cost of an increase in complexity in the
framework itself).

Change-Id: I7f3d06b2eb58c1b26a846791a13b0037f32c8013
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

build: unify verbosity handling

This change introduces a few helper variables for dealing with verbose
and silent build modes: `silent`, `verbose`, `q` and `s`.

The `silent` and `verbose` variables

build: unify verbosity handling

This change introduces a few helper variables for dealing with verbose
and silent build modes: `silent`, `verbose`, `q` and `s`.

The `silent` and `verbose` variables are boolean values determining
whether the build system has been configured to run silently or
verbosely respectively (i.e. with `--silent` or `V=1`).

These two modes cannot be used together - if `silent` is truthy then
`verbose` is always falsy. As such:

make --silent V=1

... results in a silent build.

In addition to these boolean variables, we also introduce two new
variables - `s` and `q` - for use in rule recipes to conditionally
suppress the output of commands.

When building silently, `s` expands to a value which disables the
command that follows, and `q` expands to a value which supppresses
echoing of the command:

$(s)echo 'This command is neither echoed nor executed'
$(q)echo 'This command is executed but not echoed'

When building verbosely, `s` expands to a value which disables the
command that follows, and `q` expands to nothing:

$(s)echo 'This command is neither echoed nor executed'
$(q)echo 'This command is executed and echoed'

In all other cases, both `s` and `q` expand to a value which suppresses
echoing of the command that follows:

$(s)echo 'This command is executed but not echoed'
$(q)echo 'This command is executed but not echoed'

The `s` variable is predominantly useful for `echo` commands, where you
always want to suppress echoing of the command itself, whilst `q` is
more useful for all other commands.

Change-Id: I8d8ff6ed714d3cb401946c52955887ed7dca602b
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...