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
