Hello, there has been no answer to my email below so I add some findings and ask again. Any hint will be a great help to me..
I guess for Q1, the kernel 'process' and busybox 'process' has many contexts that are using the same page table.
(previously I though context 0 is the kernel, and context 1 is the busybox) Is my understading correct?
for Q2. I found I get page fault for this access which is legal, and I was following the page fault trap handler which should fill in the missing entry in the page table. (though I'm loolking into the previous loading problem..)
The frame buffer address is not using cache and it's for DMA. my new question becomes is the DMA address contained in one of the vm_area_struct list of the mm_struct of the current process? (I'll check later when I can)
(I was reading
http://www.tldp.org/LDP/tlk/mm/memory.html which was helpful.)
for Q3, I think now I understand why ( it's 4 bit mastk, 4 bit shift left and another *4 so 10 bit shift which is 1024 bytes)
Any hint would be greatly appreciated.
Thank you! Chan
From : "Chan Kim" <ckim@xxxxxxxxxx>
Sent : 2014-03-22 11:57:31 ( +09:00 )
To : kernelnewbies@xxxxxxxxxxxxxxxxx <kernelnewbies@xxxxxxxxxxxxxxxxx>
Cc :
Subject : some questions on sparc reference memory management (SRMMU)
Sent : 2014-03-22 11:57:31 ( +09:00 )
To : kernelnewbies@xxxxxxxxxxxxxxxxx <kernelnewbies@xxxxxxxxxxxxxxxxx>
Cc :
Subject : some questions on sparc reference memory management (SRMMU)
Hi, folks,
While I was trying to open a shell on the LCD, I found printk from inside the kernel and printf from user side busybox
use the same frame buffer driver (and eventually bit blitting functions) as my previous email said.
use the same frame buffer driver (and eventually bit blitting functions) as my previous email said.
I later found the reason printf doesn't work in my case is that the page table is not correctly setup for context 1 which
the bit blitting function is in while accessing the frame buffer memory for printf. When doing the printk, the context is 0.
the bit blitting function is in while accessing the frame buffer memory for printf. When doing the printk, the context is 0.
I used srmmu_swprobe function to check the page table entry for the frame buffer address. I can get the physical address
corresponding to the virtual address.(by the way, I think the address for pixel data is a dma address which should bypass
cache, and it still needs virtual-physical address translation..)
corresponding to the virtual address.(by the way, I think the address for pixel data is a dma address which should bypass
cache, and it still needs virtual-physical address translation..)
When srmmu_swprobe probes the page table, it bypasses the mmu translation of course. The context table base and
current context value are kept in MMU registers (in 0x100 and 0x200 each)
current context value are kept in MMU registers (in 0x100 and 0x200 each)
What I found : when in context 0 and context 1
context table address was the same 0x60540800. and then I just found while blitting the printk text, the current context value is 0
and all the entries in the context table is 0x6054001.(I checked for context 0,1,2 entries). They are all the same!
But while doing printf, (current context was 1), all the entries in the context table was 0x6054a41. (also checked for context 0,1,2)
context table address was the same 0x60540800. and then I just found while blitting the printk text, the current context value is 0
and all the entries in the context table is 0x6054001.(I checked for context 0,1,2 entries). They are all the same!
But while doing printf, (current context was 1), all the entries in the context table was 0x6054a41. (also checked for context 0,1,2)
in context 0, the level 0 table starts at 0x60540000 and for context 1 it starts at 0x6054a400. (first level table has 1024 bytes,
so the pointer is interpreted as pointing 1024 byte chunks, so right 4 bits are masked off and it is 4 bit left shifted,= 256 words)
so the pointer is interpreted as pointing 1024 byte chunks, so right 4 bits are masked off and it is 4 bit left shifted,= 256 words)
Q1 : I previously thought the context table should remain the same and be added an entry as new context is added but
why has the pointer for context 0 been changed after busybox loading?
Q2 : and in context 1 case,(where I can't access the frame buffer), when I read the address pointed to by the context 1 pointer,
it reads zero. so something is wrong. It should contain either PTE or PTD. When does the OS setup the page table? I guess
it does so while loading a program using sys_execve. somebody please confirm.. where in the code should I look?
it reads zero. so something is wrong. It should contain either PTE or PTD. When does the OS setup the page table? I guess
it does so while loading a program using sys_execve. somebody please confirm.. where in the code should I look?
Q3 : when reading the value pointed to by the context table entry, the code below is used.
(I'm using a sparc processor designed in our team.)
ptr = (pgd & SRMMU_PTD_PMASK) << 4; // SRMMU_PTD_PMASK is 0xffff fff0 in our case.
ptr += ((((vaddr) >> SNAKE_PGD_SH) & SNAKE_PGD_M) * 4); // SNAKE_PGD_SH is 24 and SNAKE_PGD_M is 0xff in our case
pmd = SNAKE_BYPASS_LOAD_PA(ptr); // pmd reads 0 when in context 1 (read bypasses mmu translation here)
in the second line, the 8 bit index from the virtual address is multiplied by 4 to make it point to 1024 byte chunks. (The first level
table is of size 1024 by the SPARC reference MMU). But in the first line, why is it 4 bit left shfited? This may take any alignment,
but is there any reason?
(I'm using a sparc processor designed in our team.)
ptr = (pgd & SRMMU_PTD_PMASK) << 4; // SRMMU_PTD_PMASK is 0xffff fff0 in our case.
ptr += ((((vaddr) >> SNAKE_PGD_SH) & SNAKE_PGD_M) * 4); // SNAKE_PGD_SH is 24 and SNAKE_PGD_M is 0xff in our case
pmd = SNAKE_BYPASS_LOAD_PA(ptr); // pmd reads 0 when in context 1 (read bypasses mmu translation here)
in the second line, the 8 bit index from the virtual address is multiplied by 4 to make it point to 1024 byte chunks. (The first level
table is of size 1024 by the SPARC reference MMU). But in the first line, why is it 4 bit left shfited? This may take any alignment,
but is there any reason?
I know I have to read more (and some part again) about the linux memory management but hope to hear some explanations or hints.
best regards,
Chan
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
