This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
loading images with redboot
- To: "Ecos-Discuss (E-mail)" <ecos-discuss at sources dot redhat dot com>
- Subject: [ECOS] loading images with redboot
- From: "Dan Conti" <danc at iobjects dot com>
- Date: Tue, 9 Oct 2001 20:23:13 -0700
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.
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
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