On Mon, 22 Apr 2024 at 14:38, Marcin Juszkiewicz <marcin.juszkiew...@linaro.org> wrote: > > W dniu 22.04.2024 o 14:56, Peter Maydell pisze: > > On Fri, 19 Apr 2024 at 19:46, Peter Maydell <peter.mayd...@linaro.org> > > 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 attempts to set > >> the ARM_FEATURE_BACKCOMPAT_CNTFRQ flag on new CPU types as a result > >> of cut-n-paste from an older CPU initfn ;-)). > >> > >> It remains the case that the machine model can override the default > >> value via the 'cntfrq' QOM property (regardless of the CPU type). > > > > This patchset turns out to break the sbsa-ref board: the > > Aarch64SbsarefMachine.test_sbsaref_alpine_linux_max_pauth_impdef > > avocado test both (a) takes rather longer to boot and (b) when > > running thinks that time is advancing very fast. > > > > I suspect this may be because the firmware hard-codes the > > generic timer clock frequency it is expecting. I've cc'd the > > sbsa-ref maintainers: is that correct? > > > > If so, we can deal with it by making the sbsa-ref board set the > > cntfrq QOM property on its CPUs to force them to the old > > frequency. However this will produce a technically-out-of-spec > > CPU when used with a v8.6-compliant CPU type, so probably we > > should do something to be able to tell the firmware the clock > > frequency (if it doesn't want to just read CNTFRQ_EL0 itself). > > 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() -> > ArmReadCntFrq() -> "mrs x0, cntfrq_el0"
Yeah, it looks like it's TF-A that hardcodes the frequency: https://github.com/ARM-software/arm-trusted-firmware/blob/c8be7c08c3b3a2330d54b58651faa9438ff34f6e/plat/qemu/qemu_sbsa/include/platform_def.h#L269 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 the watchdog timer frequency are the same, which is a bit dubious IMHO. It also seems to be hardcoded in TF-A's support for the virt board too, annoyingly. thanks -- PMM