Hi Simon,<div><br></div><div>I have figured out and solved my problem.</div><div><span style="background-color:rgb(255,255,255);color:rgb(87,87,87);font-family:intel-neo-sans-1,intel-neo-sans-2,tahoma,helvetica,sans-serif;font-size:13px;line-height:19px"><br>
</span></div><div><span style="background-color:rgb(255,255,255);font-family:intel-neo-sans-1,intel-neo-sans-2,tahoma,helvetica,sans-serif;font-size:13px;line-height:19px">I just made a basic mistake.</span></div><div><span style="background-color:rgb(255,255,255);font-family:intel-neo-sans-1,intel-neo-sans-2,tahoma,helvetica,sans-serif;font-size:13px;line-height:19px">I defined the base address with type of "int*" (mapped to physical addr of 0xf9008000), and added the offset (0x224) directly when access the memory, which must target a wrong location (base_addr + sizeof(int) * 0x224).</span></div>
<div><br></div><div>Thank you very much.</div><div>Regards,</div><div>Zhiquan</div><div><br><div class="gmail_quote">On Tue, Jan 15, 2013 at 3:34 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 bgcolor="#FFFFFF" text="#000000">
<div>I don't have it in front of me right
now, but there should be a file named <a href="http://lut_mapping.vi" target="_blank">lut_mapping.vi</a> (or similar)
in the obj directory that's created after you execute bootscc.sh.
That has a listing of all default LUT mappings and explanations,
which should include the one you're looking for.<span class="HOEnZb"><font color="#888888"><br>
<br>
Simon</font></span><div><div class="h5"><br>
<br>
On 13-01-13 09:20 PM, Zhiquan Lai wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
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>
<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><font color="#888888"><br>
<br>
Simon<br>
</font></span></blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>