1. Home
  2. Embedded Linux
  3. Cannot call C function in "Simple" boot loader

Cannot call C function in "Simple" boot loader

Hello,

I am trying to boot up a monta vista linux kernel with vxworks boot loader. The vxworks boot loader can load the "Simple" boot loader and execute it with no problem. But when relocate.S tried to call the C function decompress_kernel() in misc-simple.c, it was stucked and can't go through. I guess there are some stack setup or something else I didn't do it right. Could you give any advice on what could be the problem during C function calling?

BTW, I found this comment in relocate.S:

=========================================================================== /* Move this code somewhere safe. This is max(load + size, end) * BIG ASSUMPTION: Addresses below 0x80000000 are assumed to be * in RAM, and addresses above 0x80000000 are assumed to be in * Flash. The cmpw instruction below does a signed integer * comparison, so when comparing a RAM address to a Flash address * the RAM address will always be greater. This allows the * relocation to work when the load address is in Flash. * r8 == load address

*/ GETSYM(r4, start) GETSYM(r5, end) sub r6,r5,r4 add r6,r8,r6 /* r6 == phys(load + size) */ ===========================================================================

I don't quite understand the assumption, i.e. addresses below

0x80000000 are RAM and above are Flash. Where is this assumption reflected in this Simple boot loader? For the board I am using, addresses below 0xFFE00100 are RAM and addresses above 0xFFEE00100 are Flash. How should I change the code (or Makefile?) according to my hardware spec?

Thanks in advance for your help!

Frank

Reply to
Frank
Loading thread data ...

Hi Frank,

I see you're still struggling over the PPC board and vxworks boot loader.

Frank wrote:

Lots of reasons. Did the relocate work? Is the cache off? If it is not then the relocation may only happen in the data cache and the instruction cache may not know about it, so that when you jump to the code, you go nowhere.

Ignore this unless you have over 2 Gigs of RAM. This is just a easy way to determine if the code is in RAM or Flash. Yes the flash is usually above the 0xffe00000 region which is over 0x80000000, and unless you have more that 2 gigs of RAM or your board maps ram from other than zero physical address (both unlikely), then you can assume that this assumtion is correct.

-- Steve

Reply to
Steven Rostedt

Hello Steve,

Yes, I am still struggling. I got some progress, but slowly. ;*( I think I have solve the problem between boot loader and linux kernel. Now I got some problems with the kernel booting up.

Right now my vxworks boot loader can start the simple boot loader and simple boot loader can take over the control and make some initialization such as serial port initialization etc. And I did get the serial 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 don't quite understand how these code can stop the program. Look like they are simply calling "start_here" and then restoring PC and MSR. But I put the break point in start_here and was sure that start_here hasn't been called. Do you have any clue?

Thanks a lot and look forard to hearing from you.

Frank

Reply to
Frank

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.