Problem with mvista booting

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hello all,

I am working on a PPC 405GP with 16MB memory custom board. I have been
stuck with some problems in mvista linux booting.

Right now my boot loader can start the simple boot loader and the
simple boot loader can take over the control and make some
initialization such as serial port initialization etc. And I did get
the console output such as
"loaded at xxxx xxxx
relocated to xxxx xxxx
zImage at xxxx xxxx
avail ram xxxx xxxx

Now booting the kernel"

But the system hangs after this output. I check the code and found the
head_4xx.S (I am using 405GP) has been called. But somehow the program
stopped at the following part:

"
/* We now have the lower 16 Meg mapped into TLB entries, and the
caches
 * ready to work.
 */

turn_on_mmu:
    li  r0,MSR_KERNEL
    mtspr   SRR1,r0
    lis r0,start_here@h
    ori r0,r0,start_here@l
    mtspr   SRR0,r0
    SYNC
    rfi             /* enables MMU */
"


I put a break point right after SYNC and before rfi. It shows me that
the program finished SYNC but stopped at rfi. I don't quite understand
how rfi can stop the program. Look like it is just simply calling
"start_here" which is stored in SRR0. But I put another break point in
start_here and was sure that
start_here hasn't been called. Does anyone can give me any clue?

Thanks in advance!


Frank

Re: Problem with mvista booting
Quoted text here. Click to load it

Ask MontaVista, that's presumably why you're paying them.  That said...

[ sneck ]

Quoted text here. Click to load it

Ooooh, the most favorite part of the kernel startup!

Quoted text here. Click to load it

The rfi instruction here is doing something extremely magic:  The
SRR0 and SRR1 registers have been configured to look like an
exception/interrupt has happened, and the rfi is going to be
doing two things:
- Changing the PC to start_here
- Enabling the MMU (possibly also turning on the caches for the first time)

This bit of code is probably the hardest to debug in the entire OS.  I
would suggest checking out the page tables that were set up before
turn_on_mmu was called, and make sure they have a correct mapping
for the virtual address of start_here.  Check the cache control/WIMG
bits, too.  If the region is marked cacheable, make sure the cache is
initialized correctly.

If you have a JTAG emulator (dunno if that works for PPCs, but it's
terribly handy on ARM architectures), you should be able to see what's
going on.  If not, well, I don't know all that much about what tools are
available for PPCs these days.  At worst, you can hang a logic analyzer
on the thing and guess based on the external bus cycles.
--
Steve Watt KD6GGD  PP-ASEL-IA          ICBM: 121W 56' 57.8" / 37N 20' 14.9"
 Internet: steve @ Watt.COM                         Whois: SW32
We've slightly trimmed the long signature. Click to see the full one.
Re: Problem with mvista booting
Quoted text here. Click to load it

How does rfi work in order to enable MMU? MSR_KERNEL is assigned to
SRR1. I checked MSR_KERNEL but it doesn't have MMU entry, or maybe I
misunderstood?



Thanks!

Frank

Re: Problem with mvista booting
Quoted text here. Click to load it

Ooh, rusty memory area now.  I seem to recall they had funny names,
something like "instruction relocation" and "data relocation".

Ah!  Google is your freind.  I think the bits are MSR_IR and MSR_DR,
and they seem to be set in MSR_KERNEL according to various things I
found.  You might like http://www.xtrj.org/ppc/ppc8.htm .

(Note: I know nothing at all about xtrj.org, and very little about
the PPC Linux, as all of my PPC work was in another OS.)
--
Steve Watt KD6GGD  PP-ASEL-IA          ICBM: 121W 56' 57.8" / 37N 20' 14.9"
 Internet: steve @ Watt.COM                         Whois: SW32
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline