GitLab

The STM32 platform port parse DT nodes to find base address to
peripherals. It does this by using its own implementation, even though
this functionality is generic and actually widely useful outside of the
STM32 code.

Re-implement fdt_get_reg_props_by_name() on top of the newly introduced
fdt_get_reg_props_by_index() function, and move it to fdt_wrapper.c.
This is removes the assumption that #address-cells and #size-cells are
always one.

Change-Id: I6d584930262c732b6e0356d98aea50b2654f789d
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

* changes:
  arm: fconf: Fix GICv3 dynamic configuration
  plat/stm32: Implement fdt_read_uint32_default() as a wrapper
  fdt/wrappers: Replace fdtw_read_cells() implementation
  plat/stm32: Use generic fdt_read_uint32_array() implementation
  fdt/wrappers: Generalise fdtw_read_array()

At the moment the fconf_populate_gicv3_config() implementation is
somewhat incomplete: First it actually fails to store the retrieved
information (the local addr[] array is going nowhere), but also it makes
quite some assumptions about the device tree passed to it: it needs to
use two address-cells and two size-cells, and also requires all five
register regions to be specified, where actually only the first two
are mandatory according to the binding (and needed by our code).

Fix this by introducing a proper generic function to retrieve "reg"
property information from a DT node:
We retrieve the #address-cells and #size-cells properties from the
parent node, then use those to extract the right values from the "reg"
property. The function takes an index to select one region of a reg
property.

This is loosely based on the STM32 implementation using "reg-names",
which we will subsume in a follow-up patch.

Change-Id: Ia59bfdf80aea4e36876c7b6ed4d153e303f482e8
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

The STM32 platform code uses its own set of FDT helper functions,
although some of them are fairly generic.

Remove the implementation of fdt_read_uint32_default() and implement it
on top of the newly introduced fdt_read_uint32() function, then convert
all users over.

This also fixes two callers, which were slightly abusing the "default"
semantic.

Change-Id: I570533362b4846e58dd797a92347de3e0e5abb75
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Our fdtw_read_cells() implementation goes to great lengths to
sanity-check every parameter and result, but leaves a big hole open:
The size of the storage the value pointer points at needs to match the
number of cells given. This can't be easily checked at compile time,
since we lose the size information by using a void pointer.
Regardless the current usage of this function is somewhat wrong anyways,
since we use it on single-element, fixed-length properties only, for
which the DT binding specifies the size.
Typically we use those functions dealing with a number of cells in DT
context to deal with *dynamically* sized properties, which depend on
other properties (#size-cells, #clock-cells, ...), to specify the number
of cells needed.

Another problem with the current implementation is the use of
ambiguously sized types (uintptr_t, size_t) together with a certain
expectation about their size. In general there is no relation between
the length of a DT property and the bitness of the code that parses the
DTB: AArch64 code could encounter 32-bit addresses (where the physical
address space is limited to 4GB [1]), while AArch32 code could read
64-bit sized properties (/memory nodes on LPAE systems, [2]).

To make this more clear, fix the potential issues and also align more
with other DT users (Linux and U-Boot), introduce functions to explicitly
read uint32 and uint64 properties. As the other DT consumers, we do this
based on the generic "read array" function.
Convert all users to use either of those two new functions, and make
sure we never use a pointer to anything other than uint32_t or uint64_t
variables directly.

This reveals (and fixes) a bug in plat_spmd_manifest.c, where we write
4 bytes into a uint16_t variable (passed via a void pointer).

Also we change the implementation of the function to better align with
other libfdt users, by using the right types (fdt32_t) and common
variable names (*prop, prop_names).

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi#n874
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/ecx-2000.dts



Change-Id: I718de960515117ac7a3331a1b177d2ec224a3890
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

The device tree parsing code for the STM32 platform is using its own FDT
helper functions, some of them being rather generic.
In particular the existing fdt_read_uint32_array() implementation is now
almost identical to the new generic code in fdt_wrappers.c, so we can
remove the ST specific version and adjust the existing callers.

Compared to the original ST implementation the new version takes a
pointer to the DTB as the first argument, and also swaps the order of
the number of cells and the pointer.

Change-Id: Id06b0f1ba4db1ad1f733be40e82c34f46638551a
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Currently our fdtw_read_array() implementation requires the length of
the property to exactly match the requested size, which makes it less
flexible for parsing generic device trees.
Also the name is slightly misleading, since we treat the cells of the
array as 32 bit unsigned integers, performing the endianess conversion.

To fix those issues and align the code more with other DT users (Linux
kernel or U-Boot), rename the function to "fdt_read_uint32_array", and
relax the length check to only check if the property covers at least the
number of cells we request.
This also changes the variable names to be more in-line with other DT
users, and switches to the proper data types.

This makes this function more useful in later patches.

Change-Id: Id86f4f588ffcb5106d4476763ecdfe35a735fa6c
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

* changes:
  linker_script: move .data section to bl_common.ld.h
  linker_script: move stacks section to bl_common.ld.h
  bl1: remove '.' from stacks section in linker script

Move the data section to the common header.

I slightly tweaked some scripts as follows:

[1] bl1.ld.S has ALIGN(16). I added DATA_ALIGN macro, which is 1
    by default, but overridden by bl1.ld.S. Currently, ALIGN(16)
    of the .data section is redundant because commit 41286590


    ("Fix boot failures on some builds linked with ld.lld.") padded
    out the previous section to work around the issue of LLD version
    <= 10.0. This will be fixed in the future release of LLVM, so
    I am keeping the proper way to align LMA.

[2] bl1.ld.S and bl2_el3.ld.S define __DATA_RAM_{START,END}__ instead
    of __DATA_{START,END}__. I put them out of the .data section.

[3] SORT_BY_ALIGNMENT() is missing tsp.ld.S, sp_min.ld.S, and
    mediatek/mt6795/bl31.ld.S. This commit adds SORT_BY_ALIGNMENT()
    for all images, so the symbol order in those three will change,
    but I do not think it is a big deal.

Change-Id: I215bb23c319f045cd88e6f4e8ee2518c67f03692
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The stacks section is the same for all BL linker scripts.

Move it to the common header file.

Change-Id: Ibd253488667ab4f69702d56ff9e9929376704f6c
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Only BL1 specifies '.' in the address field of the stacks section.

Commit 4f59d835 ("Make BL1 RO and RW base addresses configurable")
added '.' on purpose but the commit message does not help to understand
why.

This commit gets rid of it in order to factor out the stacks section
into include/common/bl_common.ld.h

I compared the build result for PLAT=qemu.

'aarch64-linux-gnu-nm -n build/qemu/release/bl1/bl1.elf' will change
as follows:

@@ -336,8 +336,8 @@
 000000000e04e0e0 d max_log_level
 000000000e04e0e4 D console_state
 000000000e04e0e5 D __DATA_RAM_END__
-000000000e04e0e5 B __STACKS_START__
 000000000e04e100 b platform_normal_stacks
+000000000e04e100 B __STACKS_START__
 000000000e04f100 b bl1_cpu_context
 000000000e04f100 B __BSS_START__
 000000000e04f100 B __STACKS_END__

After this change, __STACKS_START__ will match to platform_normal_stacks,
and I think it makes more sense.

'aarch64-linux-gnu-objdump -h build/qemu/release/bl1/bl1.elf' will change
as follows:

@@ -9,11 +9,11 @@
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   2 .data         000000e5  000000000e04e000  0000000000004a60  0001e000  2**4
                   CONTENTS, ALLOC, LOAD, DATA
-  3 stacks        0000101b  000000000e04e0e5  000000000e04e0e5  0001e0e5  2**6
+  3 stacks        00001000  000000000e04e100  0000000000004b45  0001e100  2**6
                   ALLOC
-  4 .bss          000007e0  000000000e04f100  000000000e04f100  0001e0e5  2**5
+  4 .bss          000007e0  000000000e04f100  0000000000004b50  0001f100  2**5
                   ALLOC
-  5 xlat_table    00006000  000000000e050000  000000000e050000  0001e0e5  2**12
+  5 xlat_table    00006000  000000000e050000  0000000000004b45  00020000  2**12
                   ALLOC
   6 coherent_ram  00000000  000000000e056000  000000000e056000  0001f000  2**12
                   CONTENTS

Sandrine pointed me to a useful document [1] to understand why LMAs of
stacks, .bss, and xlat_table section have changed.

Before this patch, they fell into this scenario:
 "If the section has a specific VMA address, then this is used as the
  LMA address as well."

With this commit, the following applies:
 "Otherwise if a memory region can be found that is compatible with the
  current section, and this region contains at least one section, then
  the LMA is set so the difference between the VMA and LMA is the same
  as the difference between the VMA and LMA of the last section in the
  located region."

Anyway, those three sections are not loaded, so the LMA changes will not
be a problem. The size of bl1.bin is still the same.

QEMU still boots successfully with this change.

A good thing is, this fixes the error for the latest LLD. If I use the
mainline LLVM, I see the following error. The alignment check will probably
be included in the LLVM 11 release, so it is better to fix it now.

$ PLAT=qemu CC=clang CROSS_COMPILE=aarch64-linux-gnu-
  [ snip ]
ld.lld: error: address (0xe04e0e5) of section stacks is not a multiple of alignment (64)
make: *** [Makefile:1050: build/qemu/release/bl1/bl1.elf] Error 1

[1]: https://sourceware.org/binutils/docs/ld/Output-Section-LMA.html#Output-Section-LMA



Change-Id: I3d2f3cc2858be8b3ce2eab3812a76d1e0b5f3a32
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
Change-Id: Ib39e53eb53521b8651fb30b7bf0058f7669569d5

RD-Daniel Config-XLR platform has four identical chips connected via a
high speed coherent CCIX link. Each chip has four Neoverse cores
connected via coherent CMN interconnect.

Change-Id: I37d1b91f2b6ba08f61c64d0288bc16a429836c08
Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>

'make doc' will now fail if Sphinx outputs any warning messages during
documentation generation.

Change-Id: I3e466af58ccf29b14a7e61037539b79ab6fc6037
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>

Change-Id: I27f7d92988fc16f68041c2ddaa8dd3a60362ddd1
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>

A5DS FPGA system timer clock frequency is 7.5Mhz.
The dt is file updated inline with the hardware
clock frequency.

Change-Id: I3f6c2e0d4a7b293175a42cf398a8730448504af9
Signed-off-by: lakshmi Kailasanathan <lakshmi.Kailasanathan@arm.com>

This commit fixes an assertion that was triggering in certain contexts:

    ERROR: mmap_add_region_check() failed. error -22
    ASSERT: lib/xlat_tables_v2/xlat_tables_core.c:790

Change-Id: Ia55b3fb4f496c8cd791ea6093d122edae0a7e92a
Signed-off-by: Chris Kay <chris.kay@arm.com>
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>

This is a fixup for patch 3ba55a3c


("docs: Update SMCCC doc, other changes for release"), where some
links names got changed but their references didn't.

Change-Id: I980d04dde338f3539a2ec1ae2e807440587b1cf5
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>

Following the messages on the mailing list regarding the possible issue around
reading DTB's information, we decided to flag the fconf feature as experimental.
A uniform approach should be used to handle properties miss and DTB validation.
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
Change-Id: Ib3c86e81fb2e89452c593f68d825d3d8f505e1fb

Updating the change log for the v2.3 release and the upcoming change log
template for v2.4 release.
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: Ice875d3c93227069738a429d4b945512af8470e9

Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: Ie842d6a9919776de151a4e9304f870aede07c47a

A small set of misc changes to ensure correctness before the v2.3
release.
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I5b4e35b3b46616df0453cecff61f5a414951cd62

Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I5a7ae778999295f3453b7ab0bfc26351e545fb8f

By writing 0 to CLUSTERPWRDN DSU register bit 0, we send an
advisory to the power controller that cluster power is not required
when all cores are powered down.

The AArch32 CLUSTERPWRDN register is architecturally mapped to the
AArch64 CLUSTERPWRDN_EL1 register

Change-Id: Ie6e67c1c7d811fa25c51e2e405ca7f59bd20c81b
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>

 - Include the platform documentation in the table of contents.

 - Add a title for the document. Without this, the platform
   documentation was listed under a 'Description' title on page
   https://trustedfirmware-a.readthedocs.io/en/latest/plat/index.html



 - Change TF-A git repository URL to point to tf.org (rather than the
   deprecated read-only mirror on Github).

 - Fix the restructuredText syntax for the FIP command line. It was
   not displayed at all on the rendered version.

Change-Id: I7a0f062bcf8e0dfc65e8f8bdd6775c497a47e619
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>