Valdis and all, I understand we cannot access the same physical memory both as cacheable and non-cacheable. and I'm pretty sure they were pointing to the same physical address. (I haven't check with mmap yet, I will try later.) The point I was confused about was the __nocache_fix operation to the address. Writing a reply email, I remembered that the __nocache_fix conversion to the address is used only before MMU setup. After MMU setup (setting the context table and PGD pointer to the MMU register), the __nocache_fix operation to the address is not used. but __nocache_fix(0xc8000320) is 0xc0540320 and In our system we don't have physical memory at 0xc0000000 ~. (we have memory at 0x60000000 ~ 0x6fffffff) seeing the definition of __nocache_fix, the input and ouput is all virtual address (VADDR). This means I can access virtual address 0xc054xxxx (nocache region) through MMU to 0x6054xxxx. 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) Can anybody give me some light on this? Thanks, Chan 보낸 사람 : "Valdis.Kletnieks@xxxxxx" <Valdis.Kletnieks@xxxxxx> 보낸 날짜 : 2014-05-20 11:31:14 ( +09:00 ) 받는 사람 : 김찬 <ckim@xxxxxxxxxx> 참조 : kernelnewbies@xxxxxxxxxxxxxxxxx <kernelnewbies@xxxxxxxxxxxxxxxxx> 제목 : Re: two virtual address pointing to same physical address On Tue, 20 May 2014 00:39:26 -0000, Chan Kim said: > But still it's confusing. Can two virtual addresses from the "same process" > (in init process, one for nocache pool, the other not) point to the same > physical address? I'm not sure what you're trying to say there. In general, the hardware tags like non-cacheable and write-combining are applied to physical addresses, not virtual. And a moment's thought will show that treating the same address (whether it's virtual or physical) as caching in one place and non-caching in another is just *asking* for a stale-data bug when the non-caching reference updates data and the caching reference thinks it's OK to use the non-flushed non-refreshed cached data. It's easy enough to test if two addresses from a single process can point to the same physical address - do something like this: /* just ensure these two map the same thing at different addresses */ foo = mmap(something,yaddayadda); bar = mmap(something,yaddayadda); /* modify via one reference */ *foo = 23; /* you probably want a barrier call here so gcc doesn't screw you */ /* Now dereference it via the other reference */ printf("And what we read back is %d\n", *bar); (Making this work is left as an exercise for the student :) And figuring out why you need a barrier is fundamental to writing bug-free code that uses shared memory. The file Documentation/memory-barriers.txt is a good place to start. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies