Michael, Please see comments below..
On Thu, 10 May 2001, machael thailer wrote: > > > turn_on_mmu: > > ..... > > SYNC > > RFI > > > >I am dealing with same problem. After the rfi (on > >turn_on_mmu) instruction an signal is generated and > >the progam counter is lost. When performing an rfi > >most of the bits of the SRR1 registers become the MSR > >bits and the SRR0 register become the next instruction > >pointer (NIA). I read the manual and if the new MSR > >value enables some pending exceptions then this > >exceptions are processed by exception priority. The > >bits modified after the rfi are MSR_IR & MSR_DR so I > >think (I am not sure yet) this bits enables a waiting > >exception of some kind and when the rfi is processed > >the exception is executed. gdb only said it recevies > >a SIGSTOP signal. I will be working with that today. > >If I found anything I will let you know. > > Now I can "turn_on_mmu" and run "start_here" . I make a mistake when I try > to debug by outputing a character vi SERIAL Port after "turn_on_mmu". > The serial port IO is 0xfe0003f8, and the "initial_bats" only do the > physical address 0~256M to virtual address 0xc0000000~0xc0000000+256M > memory-mapping. To make the serial port output work, we have to do > additional memory-mapping from physical address 0xf000000-0xffffffff to > virtual address 0xf0000000~0xffffffff as following: > > initial_bats: > ...... > ...... > mtspr DBAT0L,r8 > mtspr DBAT0U,r11 > mtspr IBAT0L,r8 > mtspr IBAT0U,r11 > > /*the start added lines */ > lis r9,0xf000 > ori r9,r9,0x1ffe > lis r8,0xf000 > ori r8,r8,0x2a > mtspr DBAT1L,r8 > mtspr DBAT1U,r9 > /*the end added lines*/ > > isync > blr > > Now I meet a new problem. I can run through here: > start_here: > ... > bl identify_machine > bl MMU_init > lis r4,2f at h > ori r4,r4,2f at l > tophys(r4,r4) > li r3,MSR_KERNEL & ~(MSR_IR|MSR_DR) > FIX_SRR1(r3,r5) > mtspr SRR0,r4 > mtspr SRR1,r3 > SYNC > RFI > > /*Here I add my serial output codes, but it outputs nothing. System seems > to halt here?*/ > > 2: > sync > tlbia > sync > > Do you have any ideas? > thank you very much. Note that it is loading the "physical" address of the "2:" label into r4. What its doing, is its telling the CPU to turn off MMU (BAT mapping) and then jumping to the "2:" label. If you add your serial output after the "2:" label, it should work again. The next stage would be to make sure MMU_init() in arch/ppc/mm/init.c will set up the right BATs you need as well (f0000000-0xffffffff), As after all hash tables are modified and such, it will then write out the new BATs saved in the "BATS" variable from MMU_init(), and then will jump to start_kernel() after turning MMU on for the last time. Hope this helps... Paul W. > > > machael thailer > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
