Hi Kornilios,<div><br></div><div>Appreciate your reply.</div><div><br></div><div>I have figured out the bug and fixed it*. But the 64 bits read from phy addr of 0xf9008224 are always be ZERO, rather than the wall-clock ticks as they said.</div>
<div>Should I need to modify the default LUT to map 0xf9008224 address to the FPGA clock ? If yes, how to do that ?</div><div><br></div><div>Besides, I want to measuring the latency of voltage scaling. And I heard that the frequency while voltage being scaled is very slow, therefore rdtsc() should be note suitable for my test. This is why I need a wall clock to measure the latency. </div>
<div><br></div><div>* The reason of this bug is that when I use paging_map_device() function to map a page to 0xf9008000 phy addr, the total device space exceeds X86_32_DEVICE_SPACE_LIMIT. So to fix the bug, I adjust X86_32_DEVICE_SPACE_LIMIT from 196 pages to 198 pages. </div>
<div><br></div><div><div>Thanks,</div><div>Zhiquan</div></div><div><br></div>
<div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hi Zhiquan,<br>
<br>
On Thu, Jan 10, 2013 at 04:50:21PM +0800, Zhiquan Lai wrote:<br>
> Hi All,<br>
><br>
> I am using Barrelfish built on intel SCC and doing some micro benchmark.<br>
> However I cann't find any wall-clock function provide by Barrelfish.<br>
><br>
> So I want to make use of the FPGA clock provided by SCC referring to<br>
> (<a href="http://intelopenport.hosted.jivesoftware.com/message/173550" target="_blank">http://intelopenport.hosted.jivesoftware.com/message/173550</a>).<br>
> As said, we can acess the 64-bit wall-clock at physical address of 0xf9008224.<br>
> Then I add some code in the function of rck.c:rck_init() to map the physical<br>
> address to a virtual address.<br>
> BUT after this modification, Barrelfish can not be booted with fault as follow:<br>
><br>
> kernel 0: exception 14 (error code 0x2): write page fault due to page not<br>
> present, while in supervisor mode<br>
> Address that caused the fault: 0x0<br>
> No active process<br>
> Faulting instruction pointer (or following instruction): 0x8010566b (0x<br>
> 10566b in binary)<br>
> EAX 0x0 EBX 0x8011e198 ECX 0xfffcd100 EDX 0xbffc ESP 0x80927b68<br>
> Top o' stack:<br>
> 0x8010566b 0x10016 0x8 0x10 0xe 0x2 0x8010566b 0x8 0x10016 0x80327000<br>
> 0x80326000 0x1 0x0 0x0 0x8 0x80 0x0 0xffffffff 0x0 0x8011e198<br>
> No GDB backend<br>
><br>
><br>
> Any suggestions are appreciated ?<br>
<br>
Haven't look at SCC's FPGA clock, but it seems that the change introduced<br>
a NULL pointer dereference. Have you tried locating where the fault<br>
occurs by disassembling the cpu driver at location 0x10566b? If not, it<br>
might give you some hints on where the problem is.<br>
<br>
Alternatively, you could use rdtsc() for taking timing measurements. See<br>
for example usr/bench/bench.c.<br>
<br>
cheers,<br>
Kornilios.<br>
<br>
--<br>
Kornilios Kourtis<br>
<br><br>
</blockquote></div><br></div>