FVP port should not program the CNTACR for the non-secure timer in the CNTCTLBase frame of the system timer implementation #170
Comments
achingupta
changed the title
|
Internal ref: http://jira.arm.com/browse/GENFW-1209 |
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this issue
Feb 1, 2016
So far, we have been blindly assuming that having access to a memory-mapped timer frame implies that the individual elements of that frame frame are already enabled. Whilst it's the firmware's job to give us non-secure access to frames in the first place, we should not rely on implementations always being generous enough to also configure CNTACR for those non-secure frames (e.g. [1]). Explicitly enable feature-level access per-frame, and verify that the access we want is really implemented before trying to make use of it. [1]:ARM-software/tf-issues#170 Signed-off-by: Robin Murphy <robin.murphy@arm.com>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this issue
Feb 26, 2016
So far, we have been blindly assuming that having access to a memory-mapped timer frame implies that the individual elements of that frame frame are already enabled. Whilst it's the firmware's job to give us non-secure access to frames in the first place, we should not rely on implementations always being generous enough to also configure CNTACR for those non-secure frames (e.g. [1]). Explicitly enable feature-level access per-frame, and verify that the access we want is really implemented before trying to make use of it. [1]:ARM-software/tf-issues#170 Acked-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Tested-by: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
ghost
pushed a commit
to crevanthsv/kernel_xiaomi_sakura
that referenced
this issue
May 15, 2021
So far, we have been blindly assuming that having access to a memory-mapped timer frame implies that the individual elements of that frame frame are already enabled. Whilst it's the firmware's job to give us non-secure access to frames in the first place, we should not rely on implementations always being generous enough to also configure CNTACR for those non-secure frames (e.g. [1]). Explicitly enable feature-level access per-frame, and verify that the access we want is really implemented before trying to make use of it. [1]:ARM-software/tf-issues#170 Acked-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Tested-by: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
coreboot-org-bot
pushed a commit
to coreboot/arm-trusted-firmware
that referenced
this issue
May 9, 2023
Normal world software is responsible to initialize CNTACR as needed. There is no existing software for msm8916 that depends on having this initialization in BL31 so drop it before anything starts to rely on it. Related issue: ARM-software/tf-issues#170 Change-Id: I9d037ab218c0c1c8a5d5523722013eba531f4728 Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The FVP port has a system level generic timer accessible to the normal world at
0x2a830000. The platform port programs the corresponding CNTACR register and sets all the bits which gives access to all aspects of this timer to the normal world.Trusted firmware should only enable non-secure access to this timer frame and the CNTACR by programming the CNTNSAR. Programming of the CNTACR should be done by normal world software.
The text was updated successfully, but these errors were encountered: