W dniu 22.04.2024 o 17:37, Marcin Juszkiewicz pisze:
It also seems to be hardcoded in TF-A's support for the virt
board too, annoyingly.
I looked at it and it seems that TF-A can just read what is in
CNTFRQ_EL0 instead of hardcoding the value.
Submitted patch:
On Mon, 22 Apr 2024 at 15:18, Peter Maydell wrote:
> I imagine that value gets written into CNTFRQ by TF-A somewhere
> along the line (and then read by EDK2 later), though I haven't
> quite found where. Plus I notice that the TF-A sbsa-watchdog-timer
> assumes that the generic-timer frequency and
W dniu 22.04.2024 o 16:18, Peter Maydell pisze:
On Mon, 22 Apr 2024 at 14:38, Marcin Juszkiewicz
From what I see in EDK2 code we read CNTFREQ_EL0:
GetPlatformTimerFreq() checks for PcdArmArchTimerFreqInHz variable which
sbsa-ref has set to 0. So it calls ArmGenericTimerGetTimerFreq() ->
On Mon, 22 Apr 2024 at 14:38, Marcin Juszkiewicz
wrote:
>
> W dniu 22.04.2024 o 14:56, Peter Maydell pisze:
> > On Fri, 19 Apr 2024 at 19:46, Peter Maydell
> > wrote:
>
> >> The upshot is that the only CPU type that changes is 'max'; but any
> >> new type we add in future (whether v8.6 or not)
W dniu 22.04.2024 o 14:56, Peter Maydell pisze:
On Fri, 19 Apr 2024 at 19:46, Peter Maydell wrote:
The upshot is that the only CPU type that changes is 'max'; but any
new type we add in future (whether v8.6 or not) will also get the new
1GHz default (assuming we spot in code review any
On Fri, 19 Apr 2024 at 19:46, Peter Maydell wrote:
>
> In previous versions of the Arm architecture, the frequency of the
> generic timers as reported in CNTFRQ_EL0 could be any IMPDEF value,
> and for QEMU we picked 62.5MHz, giving a timer tick period of 16ns.
> In Armv8.6, the architecture
In previous versions of the Arm architecture, the frequency of the
generic timers as reported in CNTFRQ_EL0 could be any IMPDEF value,
and for QEMU we picked 62.5MHz, giving a timer tick period of 16ns.
In Armv8.6, the architecture standardized this frequency to 1GHz.
Because there is no ID
