hi all,
Now when i debug the Linux kernel on Fast Model (A15x1+A7x1), i found the generic timer's frequency cannot work properly.
In the boot-wrapper, it has set the frequency as 24MHz; and i also use the modeldebugger to confirm it has been set successfully. But after the linux kernel bootup, i saw the counter register increased quicker than 24MHz, so that the kernel cannot get the correct timestamp.
I'm not sure it's a issue originally come from the model? Or i miss something. There have method to fix this issue? Any suggestion will be appreciate.
On 19 November 2012 00:52, Leo Yan leoy@marvell.com wrote:
Now when i debug the Linux kernel on Fast Model (A15x1+A7x1), i found the generic timer's frequency cannot work properly.
In the boot-wrapper, it has set the frequency as 24MHz; and i also use the modeldebugger to confirm it has been set successfully. But after the linux kernel bootup, i saw the counter register increased quicker than 24MHz, so that the kernel cannot get the correct timestamp.
I'm not sure it's a issue originally come from the model? Or i miss something. There have method to fix this issue? Any suggestion will be appreciate.
The timer on the model is not wall-clock (or real) time. It increments based on the number of instructions executed and it quickly gets out of sync with the real time. We found that 100MHz got closer but it is highly dependent on the host machine.
On 11/19/2012 07:40 PM, Catalin Marinas wrote:
On 19 November 2012 00:52, Leo Yan leoy@marvell.com wrote:
Now when i debug the Linux kernel on Fast Model (A15x1+A7x1), i found the generic timer's frequency cannot work properly.
In the boot-wrapper, it has set the frequency as 24MHz; and i also use the modeldebugger to confirm it has been set successfully. But after the linux kernel bootup, i saw the counter register increased quicker than 24MHz, so that the kernel cannot get the correct timestamp.
I'm not sure it's a issue originally come from the model? Or i miss something. There have method to fix this issue? Any suggestion will be appreciate.
The timer on the model is not wall-clock (or real) time. It increments based on the number of instructions executed and it quickly gets out of sync with the real time. We found that 100MHz got closer but it is highly dependent on the host machine.
Thx for the answer, it's identical with what i see on my pc.
On the other hand, the sp804 timers looks like can work well; so if we want to do some profiling tasks with fast model, we can use sp804 timer as a trust timekeeping?
Thx, Leo Yan
On Tue, Nov 20, 2012 at 01:12:35AM +0000, Leo Yan wrote:
On 11/19/2012 07:40 PM, Catalin Marinas wrote:
On 19 November 2012 00:52, Leo Yan leoy@marvell.com wrote:
Now when i debug the Linux kernel on Fast Model (A15x1+A7x1), i found the generic timer's frequency cannot work properly.
In the boot-wrapper, it has set the frequency as 24MHz; and i also use the modeldebugger to confirm it has been set successfully. But after the linux kernel bootup, i saw the counter register increased quicker than 24MHz, so that the kernel cannot get the correct timestamp.
I'm not sure it's a issue originally come from the model? Or i miss something. There have method to fix this issue? Any suggestion will be appreciate.
The timer on the model is not wall-clock (or real) time. It increments based on the number of instructions executed and it quickly gets out of sync with the real time. We found that 100MHz got closer but it is highly dependent on the host machine.
Thx for the answer, it's identical with what i see on my pc.
On the other hand, the sp804 timers looks like can work well; so if we want to do some profiling tasks with fast model, we can use sp804 timer as a trust timekeeping?
If you want to do any (rough) software profiling, you need to use the virtual time that the model provides since this would give a constant simulated relative CPU speed. If you compare the simulated speed to the real time, you are just profiling the model JIT compiler.
Currently all the timers that the fast model provides are entirely virtual.
linaro-kernel@lists.linaro.org
-
Catalin Marinas -
Leo Yan