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"
Sent : 2014-03-22 11:57:31 ( +09:00 )
To : kernelnewbies@kernelnewbies.org
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.
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.
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..)
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)
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)
in context 0, the level 0 table starts at 0x6054 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)
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?
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 0x 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@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
