Hi Simon,<div><br></div><div>Thanks for your advice.</div><div><br></div><div>Now I am considering what value* should I write into the LUT entry to map the clock registers.</div><div><br></div><div>Each LUT entry contains 10 bits for the upper 10 bits in new memory address, 8 bits for the tile </div>
<div>destination ID, 3 bits for the destination sub-ID, and 1 bit for MIU bypass.</div><div><br>I still can not find any reference about what should be filled in this bits for that clock registers.</div><div><br></div><div>
Thanks</div><div>Zhiquan<br><br><div class="gmail_quote">On Mon, Jan 14, 2013 at 9:26 AM, Simon Peter <span dir="ltr"><<a href="mailto:speter@inf.ethz.ch" target="_blank">speter@inf.ethz.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have figured out the bug and fixed it*. But the 64 bits read from phy<br>
addr of 0xf9008224 are always be ZERO, rather than the wall-clock ticks<br>
as they said.<br>
Should I need to modify the default LUT to map 0xf9008224 address to the<br>
FPGA clock ? If yes, how to do that ?<br>
</blockquote>
<br></div>
I believe, yes, as we didn't bother to map the FPGA pages we didn't touch and this page might be part of that. You can add a mapping in kernel/arch/scc/rck.c, in rck_init(). Feel free to extend X86_32_DEVICE_SPACE_LIMIT for that (there's no hardware limit).<span class="HOEnZb"><font color="#888888"><br>
<br>
Simon<br>
</font></span></blockquote></div><br></div>