| /rk3399_ARM-atf/bl32/sp_min/aarch32/ |
| H A D | entrypoint.S | 4779becd386cbaa1c1871d3e887704d63492ffb0 Wed Aug 06 08:18:49 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> refactor(el3-runtime): streamline cpu_data assembly offsets using the cpu_ops template
The cpu_data structure, just like cpu_ops, is collection of disparate
data that must be accessible from both C and assembly. Achieving this is
tricky as there is no way to export structure offsets from C directly so
they must be manually recreated with `#define`s and asserts. However,
the cpu_data structure is quite old and the assembly offsets are a
patchwork of additions and extremely difficult to reason with and
modify. In fact, certain currently unused builds with
ENABLE_RUNTIME_INSTRUMENTATION=1 fail to build.
To untangle this, convert the assembly offsets to the pattern used for
the cpu_ops structure. That is, first define the sizes of every member,
as generically as possible, and then chain their offsets one after the
other. To make sure this is always correct, add a CASSERT for the offset
of every member. This makes it easy to modify the structure and fixes
the build failures.
Change-Id: I61aeb55e9c494896663a3c719c10e3c072f56349
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/bl31/aarch64/ |
| H A D | crash_reporting.S | 4779becd386cbaa1c1871d3e887704d63492ffb0 Wed Aug 06 08:18:49 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> refactor(el3-runtime): streamline cpu_data assembly offsets using the cpu_ops template
The cpu_data structure, just like cpu_ops, is collection of disparate
data that must be accessible from both C and assembly. Achieving this is
tricky as there is no way to export structure offsets from C directly so
they must be manually recreated with `#define`s and asserts. However,
the cpu_data structure is quite old and the assembly offsets are a
patchwork of additions and extremely difficult to reason with and
modify. In fact, certain currently unused builds with
ENABLE_RUNTIME_INSTRUMENTATION=1 fail to build.
To untangle this, convert the assembly offsets to the pattern used for
the cpu_ops structure. That is, first define the sizes of every member,
as generically as possible, and then chain their offsets one after the
other. To make sure this is always correct, add a CASSERT for the offset
of every member. This makes it easy to modify the structure and fixes
the build failures.
Change-Id: I61aeb55e9c494896663a3c719c10e3c072f56349
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| H A D | runtime_exceptions.S | 4779becd386cbaa1c1871d3e887704d63492ffb0 Wed Aug 06 08:18:49 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> refactor(el3-runtime): streamline cpu_data assembly offsets using the cpu_ops template
The cpu_data structure, just like cpu_ops, is collection of disparate
data that must be accessible from both C and assembly. Achieving this is
tricky as there is no way to export structure offsets from C directly so
they must be manually recreated with `#define`s and asserts. However,
the cpu_data structure is quite old and the assembly offsets are a
patchwork of additions and extremely difficult to reason with and
modify. In fact, certain currently unused builds with
ENABLE_RUNTIME_INSTRUMENTATION=1 fail to build.
To untangle this, convert the assembly offsets to the pattern used for
the cpu_ops structure. That is, first define the sizes of every member,
as generically as possible, and then chain their offsets one after the
other. To make sure this is always correct, add a CASSERT for the offset
of every member. This makes it easy to modify the structure and fixes
the build failures.
Change-Id: I61aeb55e9c494896663a3c719c10e3c072f56349
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/include/lib/el3_runtime/ |
| H A D | cpu_data.h | 4779becd386cbaa1c1871d3e887704d63492ffb0 Wed Aug 06 08:18:49 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> refactor(el3-runtime): streamline cpu_data assembly offsets using the cpu_ops template
The cpu_data structure, just like cpu_ops, is collection of disparate
data that must be accessible from both C and assembly. Achieving this is
tricky as there is no way to export structure offsets from C directly so
they must be manually recreated with `#define`s and asserts. However,
the cpu_data structure is quite old and the assembly offsets are a
patchwork of additions and extremely difficult to reason with and
modify. In fact, certain currently unused builds with
ENABLE_RUNTIME_INSTRUMENTATION=1 fail to build.
To untangle this, convert the assembly offsets to the pattern used for
the cpu_ops structure. That is, first define the sizes of every member,
as generically as possible, and then chain their offsets one after the
other. To make sure this is always correct, add a CASSERT for the offset
of every member. This makes it easy to modify the structure and fixes
the build failures.
Change-Id: I61aeb55e9c494896663a3c719c10e3c072f56349
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/include/lib/ |
| H A D | utils_def.h | 4779becd386cbaa1c1871d3e887704d63492ffb0 Wed Aug 06 08:18:49 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> refactor(el3-runtime): streamline cpu_data assembly offsets using the cpu_ops template
The cpu_data structure, just like cpu_ops, is collection of disparate
data that must be accessible from both C and assembly. Achieving this is
tricky as there is no way to export structure offsets from C directly so
they must be manually recreated with `#define`s and asserts. However,
the cpu_data structure is quite old and the assembly offsets are a
patchwork of additions and extremely difficult to reason with and
modify. In fact, certain currently unused builds with
ENABLE_RUNTIME_INSTRUMENTATION=1 fail to build.
To untangle this, convert the assembly offsets to the pattern used for
the cpu_ops structure. That is, first define the sizes of every member,
as generically as possible, and then chain their offsets one after the
other. To make sure this is always correct, add a CASSERT for the offset
of every member. This makes it easy to modify the structure and fixes
the build failures.
Change-Id: I61aeb55e9c494896663a3c719c10e3c072f56349
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|
| /rk3399_ARM-atf/lib/el3_runtime/aarch64/ |
| H A D | context.S | 4779becd386cbaa1c1871d3e887704d63492ffb0 Wed Aug 06 08:18:49 UTC 2025 Boyan Karatotev <boyan.karatotev@arm.com> refactor(el3-runtime): streamline cpu_data assembly offsets using the cpu_ops template
The cpu_data structure, just like cpu_ops, is collection of disparate
data that must be accessible from both C and assembly. Achieving this is
tricky as there is no way to export structure offsets from C directly so
they must be manually recreated with `#define`s and asserts. However,
the cpu_data structure is quite old and the assembly offsets are a
patchwork of additions and extremely difficult to reason with and
modify. In fact, certain currently unused builds with
ENABLE_RUNTIME_INSTRUMENTATION=1 fail to build.
To untangle this, convert the assembly offsets to the pattern used for
the cpu_ops structure. That is, first define the sizes of every member,
as generically as possible, and then chain their offsets one after the
other. To make sure this is always correct, add a CASSERT for the offset
of every member. This makes it easy to modify the structure and fixes
the build failures.
Change-Id: I61aeb55e9c494896663a3c719c10e3c072f56349
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
|