CONFIG_PIN_TLB experiments

[Marcelo Tosatti]

> >>When you load the Mx_EPN of the pinned area is the EV bit being set?
> >
> >
> >Yep.
> >
> >
> >"MD_RAM1" (SPR 826) is set:  
> >
> >SPR  826 : 0x00007fff        32767       <- "0x00007fff" was 0x00007f00"
> >					     
> >Bits 17 and 18 are set. Their meaning is: "Change bit for DTLB entry" and 
> >"Entry valid flag" respectively. 
> >Bits 19...23 are also set, they represent supervisor access. Note that 
> >bit 23 "supervisor access type" is set: 0 is read-only, 1 is read-write.
> >
> >so everything looks OK here.
> >
> >"MD_RAM0":
> >
> >SPR  825 : 0x00000fe0         4064
> >
> >Bits 20...26 are set. 
> >
> >20-22: 8Mbyte page set.
> >23-26: APGI (access protection group in 1's complement) set. It is 
> >zero (1111 in 1's complement).
> >27: guarded memory not set.
> >
> >"MD_CAM":
> >
> >SPR  824 : 0xc00000f0  -1073741584
> >
> >Bits 24-27 are set. 
> >
> >24-26 is "page size" (111 = 8Mb) and 27 indicates "shared page" 
> >(ASID comparisong disabled). 
> >
> >The 8Mbyte page is used at boot, from "start_here" until "MMU_init()" 
> >gets called... 
> >
> >The manual says, section "9.3 Address Translation" 
> >
> >"When TLB logic detects that a new effective page number (EPN) overlaps 
> >one in the TLB (when taking into account page sizes, subpage validity 
> >flags,
> >user/supervisor state, etc. the new EPN is written and the old one is 
> >invalidated." 
> >
> >I'm trying to boot a kernel which does not create kernel pte's 
> >from 0xc000000 till 0xc080000. 
> >
> 
> Well, looking at the sources I currently have, 2.6.8 and 2.4.27, I 
> noticed that InstructionTLBMiss in 2.6 is missing some ifdefs that the 
> 2.4 has that pertain to TLB pinning. Otherwise the code appears 
> basically the same. 

Hi Conn,

Those changes shouldnt be pertinent... I believeCONFIG_PIN_TLB never worked 
on 2.4 either.