Hi Guru,
It's not possible to change the cpu clock from these registers. They're simply
there to make the kernel or boot loader happy when it reads them. We have been
working on implementing the ability to change the clock frequencies at run time
in gem5 and you can see the new ClockedObjects in the near future we plan to
submit more patches that makes frequency changes possible, but it's not there
yet.
Ali
On Jan 17, 2013, at 5:56 PM, Guru Prasad <gurup...@buffalo.edu> wrote:
> I had some general questions regarding implementation of DVFS on Gem5. I
> noticed that the cpufreq driver achieves Frequency Scaling by writing values
> into a memory-mapped register(?). I also noticed that Gem5 supports this
> register for the ARM RealView platform.
> However, writes to this register don't seem to reflect. Perhaps only certain
> values are permitted (cpufreq has a pre determined table of values that it
> uses)..or perhaps I'm not following the correct write procedure for this
> register (I did unlock REALVIEW_SYS_LOCK).
>
> Upon running my syscall on m5.opt, I noticed that the simulation seems to
> throw up a warning that says
>
> warn: CP14 unimplemented crn[14], opc1[7], crm[15], opc2[7]
>
>
> The syscall is implemented as follows
>
>
> #define REALVIEW_SYS_LOCK_VAL 0xA05F
>
> #define REALVIEW_SYS_OSC0_OFFSET 0x0C
> #define REALVIEW_SYS_LOCK_OFFSET 0x20
>
> #define REALVIEW_SYS_BASE 0x10000000
> #define REALVIEW_SYS_OSC0 (REALVIEW_SYS_BASE +
> REALVIEW_SYS_OSC0_OFFSET)
> #define REALVIEW_SYS_LOCK (REALVIEW_SYS_BASE +
> REALVIEW_SYS_LOCK_OFFSET)
>
>
> asmlinkage long sys_cpufreq_set(unsigned int freq, char *msg) {
> void __iomem *lock_ctrl = __io_address(REALVIEW_SYS_LOCK);
> unsigned int lock_val = (*((unsigned int *) lock_ctrl));
> char *val = kmalloc(sizeof(char) * 16, GFP_KERNEL);
>
>
> __raw_writel(REALVIEW_SYS_LOCK_VAL, lock_ctrl);
> ...
> }
>
> Please correct me if I'm wrong...
> As for data-flow within Gem5, I believe that everything begins with creation
> of Packets. For the ARM architecture, this seems to happen in
> table_walker.cc.
> Is there any documentation as to how the instructions are stripped from the
> packet and what the Gem5 does while decoding the instructions?
>
> Although my system call implements a lot of code that is copied from the
> kernel sources, is there any way for me to verify that I am in fact reading
> the register and not some random portion of physical memory?
>
>
> Could someone point me to where to start implementing DVFS on Gem5?
>
>
> Regards
> Guru Prasad
> _______________________________________________
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
