<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div id="ezFormProc_div" style="FONT-SIZE: 10pt; FONT-FAMILY: 굴림">
<div id="msgbody">
<div>
<div style="LINE-HEIGHT: 20pt"><br>
FYI, </div>
<div style="LINE-HEIGHT: 20pt">I found out this morning, there is a SRMMU setting with initial page table before linux start_kernel starts.
</div>
<div style="LINE-HEIGHT: 20pt">The page table directs 0xc0000000 to 0x60000000.<br>
Chan</div>
<div id="MailSignSent" style="LINE-HEIGHT: 20pt"><br>
</div>
<div id="ORGMAIL_CONTENT" style="LINE-HEIGHT: 20pt">
<hr tabindex="-1">
<b>보낸 사람 : </b>"Chan Kim" <ckim@etri.re.kr><br>
<b>보낸 날짜 : </b>2014-05-20 22:29:08 ( +09:00 )<br>
<b>받는 사람 : </b>Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu><br>
<b>참조 : </b>kernelnewbies@kernelnewbies.org <kernelnewbies@kernelnewbies.org><br>
<b>제목 : </b>Re: two virtual address pointing to same physical address<br>
<br>
Valdis and all,<br>
I understand we cannot access the same physical memory both as cacheable and non-cacheable.<br>
and I'm pretty sure they were pointing to the same physical address. (I haven't check with mmap yet, I will try later.)<br>
The point I was confused about was the __nocache_fix operation to the address.<br>
Writing a reply email, I remembered that the __nocache_fix conversion to the address is used only before MMU setup.<br>
After MMU setup (setting the context table and PGD pointer to the MMU register), the __nocache_fix operation to the address is not used.<br>
but __nocache_fix(0xc8000320) is 0xc0540320 and In our system we don't have physical memory at 0xc0000000 ~.
<br>
(we have memory at 0x60000000 ~ 0x6fffffff)<br>
seeing the definition of __nocache_fix, the input and ouput is all virtual address (VADDR).
<br>
This means I can access virtual address 0xc054xxxx (nocache region) through MMU to 0x6054xxxx.<br>
Maybe before the MMU setup, somewhere at a previous point, the 0xc054.... -> 0x6054... virtual->physical conversion may have been setup to the SRMMU. I have to check. (in the prom_stage, or very early in the init)<br>
Can anybody give me some light on this?<br>
Thanks,<br>
Chan<br>
<br>
<br>
<br>
보낸 사람 : "Valdis.Kletnieks@vt.edu" <VALDIS.KLETNIEKS@VT.EDU><br>
보낸 날짜 : 2014-05-20 11:31:14 ( +09:00 )<br>
받는 사람 : 김찬 <CKIM@ETRI.RE.KR><br>
참조 : kernelnewbies@kernelnewbies.org <KERNELNEWBIES@KERNELNEWBIES.ORG><br>
제목 : Re: two virtual address pointing to same physical address<br>
<br>
On Tue, 20 May 2014 00:39:26 -0000, Chan Kim said:<br>
> But still it's confusing. Can two virtual addresses from the "same process"<br>
> (in init process, one for nocache pool, the other not) point to the same<br>
> physical address?<br>
<br>
I'm not sure what you're trying to say there. In general, the hardware<br>
tags like non-cacheable and write-combining are applied to physical addresses,<br>
not virtual.<br>
<br>
And a moment's thought will show that treating the same address (whether it's<br>
virtual or physical) as caching in one place and non-caching in another is just<br>
*asking* for a stale-data bug when the non-caching reference updates data and<br>
the caching reference thinks it's OK to use the non-flushed non-refreshed<br>
cached data.<br>
<br>
It's easy enough to test if two addresses from a single process can<br>
point to the same physical address - do something like this:<br>
<br>
/* just ensure these two map the same thing at different addresses */<br>
foo = mmap(something,yaddayadda);<br>
bar = mmap(something,yaddayadda);<br>
/* modify via one reference */<br>
*foo = 23;<br>
/* you probably want a barrier call here so gcc doesn't screw you */<br>
/* Now dereference it via the other reference */<br>
printf("And what we read back is %d\n", *bar);<br>
<br>
(Making this work is left as an exercise for the student :)<br>
<br>
And figuring out why you need a barrier is fundamental to writing bug-free<br>
code that uses shared memory. The file Documentation/memory-barriers.txt<br>
is a good place to start.<br>
_______________________________________________<br>
Kernelnewbies mailing list<br>
Kernelnewbies@kernelnewbies.org<br>
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies<br>
</div>
</div>
</div>
</div>
</body>
</html>