> Hi all, > > After commenting out the BCSR lines on m82xx_board_init as Dan > suggested, some problem still prevents kernel 2.6.10-rc1 from > running in ads8272 board. > > After running MMU_init, next step in head.S is this > > /* > * Go back to running unmapped so we can load up new values > * for SDR1 (hash table pointer) and the segment registers > * and change to using our exception vectors. > */ > 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 > /* Load up the kernel context */ > 2: bl load_up_mmu > > which is not clear for me. Here, the execution flow breaks > in RFI and never arrives to "bl load_up_mmu". The value of > SRR0 and SRR1 before RFI is: >
RFI = Return From Interrupt. In normal usage the current address is copied into SRR0 when an exception occurs so the processor will return to that point with an RFI. So this code is 'faking out' the RFI instruction to return to 2: Are you maybe trying to trace through this code? If so, and depending on your debugger, you may not be able to. If your debugger uses trace or some other exception to do single step, once you get past mtspr SRR0,r4 the single step exception will overwrite the correct SRR0. You can see if this is the case by only tracing to mtspr SRR0,r4 and then putting a breakpoint at 2: Good luck, Mark Chambers
