difference between vxWorks.bin and vxWorks.st?
Wang,Xiaoguang(Freeman)
What's the file format of vxWorks.bin? Or bootrom.bin?
In my system. vxWorks.st is coff-little endian as reported by objdump. But
objdump can't recognize the file format of vxWorks.bin.
What are the difference between the two file formats? Where is each of them
used for?
Thanks for your help.
Xiaoguang
Martin Read
Wang,Xiaoguang(Freeman) <freema...@marconi.com> wrote:
>Hi, List
>
>What's the file format of vxWorks.bin? Or bootrom.bin?
>
>In my system. vxWorks.st is coff-little endian as reported by objdump. But
>objdump can't recognize the file format of vxWorks.bin.
.bin files are raw binary images. So, "bootrom.bin" is a bootable image
of your boot ROM - just blow it into flash at the right location and
hey presto, you've got a bootable system using that boot ROM.
Yrs,
Martin
Wang,Xiaoguang(Freeman)
cofftobin from vxWorks.st. But it seems that the symbol table was
changed --> all function addresses are different in the two versions of
images.
It makes sense to me. But is there a formula in the address change?
I can read the symbol information from vxWorks.st, but the actual address
when the program is running in the target is different from that in COFF
image.
Anybody familiar with cofftobin? Or is there a tool to read information from
.bin file? Or any documents describing the file format of .bin or .hex file
that I can use to write a tool to do this?
Thanks
Martin Read <mpr...@chiark.greenend.org.uk> wrote in message
news:koE*UU...@news.chiark.greenend.org.uk...
Wang,Xiaoguang(Freeman)
It's a custom board, arm sa110 cpu, flash&ram. The image is running on a
switch blade. When power up, the switch is responsible to write the
image(compressed) to each blade and then let those blades boot up. The file
written into the flash of each blade is a gzip version of .bin image.
I'll check those variables soon.
Bill Pringlemeir <bpring...@yahoo.com> wrote in message
news:uhf14d...@yahoo.com...
> >>>>> "WX" == Wang,Xiaoguang(Freeman) <freema...@marconi.com> writes:
>
> The addresses should not be different. How is the image loaded to
> your target? Is the address always the same? I hope so. You must
> specify the load address in the BSP. This is done by editing the
> config.h and the Makefile in the BSP directory. I don't know how to
> do this with projects. At any rate some of the variables are,
>
> ROM_TEXT_ADRS,
> ROM_SIZE,
> RAM_LOW_ADRS,
> RAM_HIGH_ADRS
>
> You need to change these values (maybe others depending on whether you
> build a `rom', `ram', `bootrom', etc version. Maybe if you gave
> particulars as to what you are trying to achieve. Ie, the board
> (custom or off the shelf), type of processor, memory types (flash,
> ram, disk, etc) we could be of more help.
>
> You definitely can not load the images that you have now! vxWorks is
> usually statically linked, although you might be able to make a
> version that was not...
>
> cheers,
> Bill Pringlemeir
>
> --
> I think I'm NOT nice ABSOLUTELY most of the time.
> Useful vxWorks URLS,
> "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"
> "http://www.xs4all.nl/~borkhuis/vxworks/vxw_pt9.html"
Wang,Xiaoguang(Freeman)
system has been running for years, and it just had some problems with the
latest build.
Since I got some stack traces of those problems and the problems are hard to
reproduce, I hope I can harness the stack trace as much as possible. But the
problem here is we just included global symbol information into the build.
So the function names reported in the stack trace are not reliable.
Fortunately, we still get the function addresses shown in the stack trace.
That's why I need a tool to find relocation information from executable
files.
I found the man page of coffToBin: it just abstracts .text and .data
sections out of a coff image. I agree with you, it seems that at least
function addresses, which is in the .text section, shouldn't be changed. But
why there are different?
The function address difference between vxWorks.st and the real stack trace
is random. It seems that coffToBin or someone else reshuffled the relocation
information.
Thanks for your patience and effort to answer my question.
Bill Pringlemeir <bpring...@yahoo.com> wrote in message
news:uhf14d...@yahoo.com...
> >>>>> "WX" == Wang,Xiaoguang(Freeman) <freema...@marconi.com> writes:
>
> WX> It makes sense to me. But is there a formula in the address
> WX> change?
>
> WX> I can read the symbol information from vxWorks.st, but the actual
> WX> address when the program is running in the target is different
> WX> from that in COFF image.
Wang,Xiaoguang(Freeman)
> How are you getting stack traces? With an in-house tool, or with the
> `tt' command from vxWorks shell (or Tornado). The addresses of a
> stack trace won't always match functions _EXACTLY_. The stack trace
> stores addresses in and around the middle of functions. It is the
> return address that is stored on a stack.
You're right. How could I assume it's the function address? Stupid.:(