1. Home
  2. Embedded Linux
  3. Problem with mvista booting

Problem with mvista booting

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

Reply to
Frank
Loading thread data ...

Ooooh, the most favorite part of the kernel startup!

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
   Free time?  There's no such thing.  It just comes in varying prices...
Reply to
Steve Watt

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

Reply to
Frank

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

formatting link

(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
   Free time?  There's no such thing.  It just comes in varying prices...
Reply to
Steve Watt

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.