This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: loading images with redboot
- To: Dan Conti <danc at iobjects dot com>
- Subject: Re: [ECOS] loading images with redboot
- From: Gary Thomas <gthomas at redhat dot com>
- Date: 10 Oct 2001 13:11:32 +0900
- Cc: "Ecos-Discuss (E-mail)" <ecos-discuss at sources dot redhat dot com>
- References: <D8DFF0AFE792914996F997E68FEC3A48F3EB@bunker.iobjects.com>
On Wed, 2001-10-10 at 12:23, Dan Conti wrote:
> Hi,
>
> i'm having problems getting redboot to execute an image for me.
> specifically, i have redboot compiled with gdb stubs support, i build my
> application image against a ram kernel. i can start my board with
> redboot on it, attach gdb to it, transfer the image through gdb, execute
> it, all with no problems.
>
> howevever, if i convert said image to srec format, transfer it via
> xmodem to redboot, and try 'go', it halts. i poked around a bit and
> tracked down one bug that was causing it to jump back into redboot
> instead of into my image; specifically, in
> hal/arch/arm/current/src/vectors.S, the reset_vector is listed as an
> UNMAPPED_PTR, so instead of getting a reset vector of 0x00020040, i get
> a reset vector of 0x00000040. fixing this doesn't seem to help though.
> the only other thing that i've noticed is that after i do 'load' i get
> lines like this from redboot:
>
> Entry point: 0x00020040, address range: 0x00020000-0x000ae0cc
>
> except the address range there makes no sense - that's 712908 bytes, my
> srec image is 1551644, and a bin objcopy of it is 581836.
0xae0cc-0x20000=0x8e0cc=581836(base 10) These numbers look right to me.
>
> any reasons why i shouldn't be able to do this? do i need to twink the
> virtual vector settings or something? all help appreciated.
>
> i'm building for an edb7xxx board. i have a cvs snapshot that's about 5
> months out of date at the moment, i'm trying to dodge upgrading.
>
> i'm getting this using the following command sequence in redboot:
>
> fis init -f
> reset
> load -v -m xmodem -b 0x20000 img
> fis create -b 0x20000 -l 1551644 -e 0x20000 -r 0x20000 img
^^^^^^^
Why noe 0x20040, which is the entry address given above?
> reset
> fis load img -b 0x20000
> go 0x20000
>
> at this point it hangs.
>
> --
> Dan Conti e danc@iobjects.com
> Software Engineer p (425) 289 0326