Hi Pau, Which version of the aarch64 DTB are you using? The generic timer driver normally queries the timer for its frequency unless it has been overridden by the DTB. Some of the old DTBs used to override the clock frequency and specified a frequency that was off by 4x. The DTB was fixed in the gem5 aarch64 kernel tree about a year ago [1].
//Andreas [1] https://github.com/gem5/linux-arm64-gem5/commit/24fd6238427aad5c212493efeb1 bba35d0538c97 On 12/02/2016, 11:29, "gem5-dev on behalf of Pau Cabre" <[email protected] on behalf of [email protected]> wrote: >Hi, > > > >If I run a linux aarch64 FullSystem simulation using this example.rcS >script >(./build/ARM/gem5.opt configs/example/fs.py --fastmem >--disk-image=aarch64-ubuntu-trusty-headless.img >--kernel=vmlinux.aarch64.20140821 >--dtb-filename=vexpress.aarch64.20140821.dtb --machine-type=VExpress_EMM64 >--script=example.rcS): > > > >#!/bin/sh > >/sbin/m5 resetstats > >sleep 10s > >/sbin/m5 exit > > > >I get the following unexpected stat value, as it should be close to 10: > > > >sim_seconds 39.737015 # Number of seconds simulated > > > >I did the same experiment with aarch32 and the result looked OK >(10.000823). > > > >The issue seems related with the hardcoded frequency of 0x1800000 Hz in >src/dev/arm/generic_timer.cc line 53, as the aarch64 kernel and/or the >disk >images (I am not an expert on this) are expecting for some reason a >frequency of 100MHz for such timer (I got the hint from this link: >https://bugs.launchpad.net/linaro-aarch64/+bug/1319863). > > > >I re-run the simulation changing the default frequency of the timer to >100000000 and then the sim_seconds stat reports 10.000866, which looks OK. >Also, such frequency change does not seem to impact the behavior of the >equivalent aarch32 simulation, as it issues an instruction to read the >frequency of the timer before issuing the instructions to programming it. >Given this, does anybody have any thought about what it is the right way >to >fix the wrong aarch64 behavior? These are the possible options that come >to >my mind: > > > >1) Just change the default frequency value to 100000000 as everything >seems >to work fine (may be dangerous tough, as the previous value is probably >the >actual frequency of the timer for the arm platforms). > >2) Modify the python GenericTimer class in order to add a new parameter >named freq (for instance), and set it to 0x1800000 or 100000000 from the >python side depending on whether it is an aarch32 or an aarch64 >simulation. >I tried this option and it also works OK. > >3) Modify the aarch64 kernel/images in order to read the frequency of the >timer before programming it (or make them know that the timer frequency is >0x1800000 Hz). This is probably the right one, but it may be too difficult >(and out of my scope). > > > >Note that I believe that it is important to fix this wrong aarch64 >behavior. >I used the "sleep 10s" command as a simple example, but this frequency >issue >is also producing wrong results for many other benchmarks (streams, >lmbench.. and probably any other benchmark relying on the system clock for >any calculation). > > > >Thanks, > >Pau > > > >_______________________________________________ >gem5-dev mailing list >[email protected] >http://m5sim.org/mailman/listinfo/gem5-dev IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
