Re: Cannot call C function in "Simple" boot loader

From: Steven Rostedt (rostedt_at_SPAMgoodmis.org)
Date: 04/19/04 

Date: Mon, 19 Apr 2004 11:18:34 -0400

Hi Frank,

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

Frank wrote:
> 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?

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.

>
> 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?

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

Relevant Pages

  • Re: MSP430 in-circuit firmware upgrade question
    ... I still don't quite understand what you mean by make the interrupt vector ... boot loader will be able to receive new application firmware ... >> over UART and program it into the flash to replace the older application. ... >> have to be copied to RAM first? ...
    (comp.arch.embedded)
  • Cannot call C function in "Simple" boot loader
    ... The vxworks boot loader can load the "Simple" boot loader and ... so when comparing a RAM address to a Flash address ... * relocation to work when the load address is in Flash. ...
    (comp.os.linux.embedded)
  • Re: S3C2410 Nand Boot
    ... initialize the RAM and copy the bootloader from flash to RAM. ... <apellerin AT adeneo DOT adetelgroup DOT com> ... doesn't have a NOR Flash to Boot Loader. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Lots of easy questions about drivers/linking
    ... >have a boot loader in FLASH that copies the BIN to RAM ... for execution. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Performance and Flash Pipelining on TI 28F12 DSPs
    ... > of "critical code" we could move to RAM. ... > from internal flash? ... Since the external RAM is as big as the internal flash, ... the timers and all other interrupts are shut off, ...
    (comp.dsp)