File type and starting address - VxWorks

This is a discussion on File type and starting address - VxWorks ; Could someone tell me what type of file this is that was created with VxWorks (unknown version)and where I would find the starting address(I was told that it is an image that contains the complete runtime application (and I presume ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: File type and starting address

  1. File type and starting address

    Could someone tell me what type of file this is that was created with
    VxWorks (unknown version)and where I would find the starting address(I
    was told that it is an image that contains the complete runtime
    application (and I presume the OS as well))?

    42 4F 4F 54 00 00 00 14 00 26 84 C8 56 78 57 6F BOOT.....&..VxWo
    72 6B 73 20 48 00 00 75 48 00 00 79 43 6F 70 79 rks H..uH..yCopy

    This is for a PowerPC board of unknown manufacture.


    Thanks in advance.

    Scott Willis


  2. Re: File type and starting address


    On 13 Sep 2005, scot.willis@gmail.com wrote:

    > Could someone tell me what type of file this is that was created
    > with VxWorks (unknown version)and where I would find the starting
    > address(I was told that it is an image that contains the complete
    > runtime application (and I presume the OS as well))?
    >
    > 42 4F 4F 54 00 00 00 14 00 26 84 C8 56 78 57 6F BOOT.....&..VxWo
    > 72 6B 73 20 48 00 00 75 48 00 00 79 43 6F 70 79 rks H..uH..yCopy
    >
    > This is for a PowerPC board of unknown manufacture.


    The text "BOOT" is not typical for a vxWorks binary image. This
    suggests that you have some other format besides the typical ROM
    image. Also, I believe that the vxWorks start code will be something
    like this,

    mov #0,R0
    b start

    .data "VxWorks Copyright, 1994 WindRiver Systems Inc."

    .align

    start:

    ; more boot code.

    As the typical string appears slightly mangled, I think that your
    format has some sort of compression. If you have access to unix,
    msys/mingw, cygwin, you can run the strings command on the image. If
    you get a lot of sub-strings [ing, etc.], it is probably LZW type
    compression.

    A typical vxWorks application links the OS and code together. It is
    more difficult to partition the application from the OS. Technically
    a monolithic image will result in the smallest code, which is often
    important for commercial consumer products.

    Do you have a picture of the PCB? Can you read the flash from a JTAG
    header? There is probably some boot sector code or some ROM inside an
    ASIC, etc.

    hth,
    Bill Pringlemeir.

    --
    The lack of reason is overcome by the passion of belief - Anonymous

    vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"

  3. Re: File type and starting address

    Thanks for the reply. No, I don't have access to the PCB or to the
    board at all.

    I also got an email saying that "BOOT" is what the PPCBug looks for
    then checks the length of the file and checksum and checks it against
    the image. It also suggested that I go to www.freescale.com and get the
    PPCBug documentation for further info.

    Thanks again.

    Scott


  4. Re: File type and starting address

    > Could someone tell me what type of file this is that was created
    > with VxWorks (unknown version)and where I would find the starting
    > address(I was told that it is an image that contains the complete
    > runtime application (and I presume the OS as well))?
    >
    > 42 4F 4F 54 00 00 00 14 00 26 84 C8 56 78 57 6F BOOT.....&..VxWo
    > 72 6B 73 20 48 00 00 75 48 00 00 79 43 6F 70 79 rks H..uH..yCopy
    >
    > This is for a PowerPC board of unknown manufacture.


    Whoever told you to look at PPCbug is most likely on the right track,
    although I suspect you need to go to Motorola instead of Freescale. I
    recognize the BOOT header from their 68K debug monitor bootrom format,
    and I guess they continued it for the PowerPC although I've never
    created a bootrom for that family. Following the keyword "BOOT" you
    have the header length of 0x14 bytes, and another number which I can't
    remember or work out what it's for, maybe a CRC. Starting at offset
    0x14 you have the start of a vxWorks ROM image, thus the first word
    there is a branch instruction to the cold start entry point, and the
    second word is a branch to the warm start entry point.

    I suggest you run the binary through the unix/linux 'strings' utility
    and see what comes out - maybe do a grep -i MVME on that output and see
    if you get anything descriptive back. If I do that for our MVME2700
    board bootrom I get this:
    MVME2300
    MVME2700
    MVME3600
    which isn't completely helpful since it lists two other model numbers
    as well, but it's a good hint. I would beware making any assumptions on
    the default boot parameter string that you'll probably find; for our
    MVME2700 BSP this is the boot line:
    dc(0,0)host:/tornado/mv2604/vxWorks h=90.0.0.1 e=90.0.0.2 u=vxworks
    which wrongly implies the file is for an MVME2604.

    HTH,

    - Andrew


  5. Re: File type and starting address

    Thanks.

    I did go to the motorola embedded communications web site and found the
    PPCBug docs.

    The other number falls just after the end of the file when I load it
    into a HEX editor.

    Scott


  6. Re: File type and starting address

    Thanks

    I found the docs on the Motorola embedded communcations site as well as
    other versions posted at various other sites.


    >From the looks of the file ran through the "strings" utility the file

    has been stripped and maybe obfuscated.

    Scott


  7. Re: File type and starting address

    Not necessarily obfuscated, it's probably been compressed, which is a
    standard part of the vxWorks build process although not all boot images
    need it (depends on the size of the flash/EPROM available). The
    compression used is standard deflate - the vxWorks toolset I have
    includes a copy of "deflate 1.0.4 Copyright 1995-1996 Jean-loup Gailly"
    which it uses when building some of our BSPs.


  8. Re: File type and starting address

    Scott Willis said the following:
    > Could someone tell me what type of file this is that was created with
    > VxWorks (unknown version)and where I would find the starting address(I
    > was told that it is an image that contains the complete runtime
    > application (and I presume the OS as well))?
    >
    > 42 4F 4F 54 00 00 00 14 00 26 84 C8 56 78 57 6F BOOT.....&..VxWo
    > 72 6B 73 20 48 00 00 75 48 00 00 79 43 6F 70 79 rks H..uH..yCopy
    >
    > This is for a PowerPC board of unknown manufacture.
    >
    >
    > Thanks in advance.
    >
    > Scott Willis
    >

    Hi Scott,

    it is no ELF file, as you can see by the letters BOOT. So it is probably
    a binary to be flashed to bootrom. In most cases you may find the entry
    point as a jump instruction saved in the last 4 bytes (Motorola MPC/IBM)
    or at offset 0x100 from beginning (Motorola MVME).

    HTH and good luck
    Michael

  9. Re: File type and starting address



    >> Could someone tell me what type of file this is that was created
    >> with VxWorks (unknown version)and where I would find the starting
    >> address(I was told that it is an image that contains the complete
    >> runtime application (and I presume the OS as well))?
    >>
    >> 42 4F 4F 54 00 00 00 14 00 26 84 C8 56 78 57 6F BOOT.....&..VxWo
    >> 72 6B 73 20 48 00 00 75 48 00 00 79 43 6F 70 79 rks H..uH..yCopy
    >>
    >> This is for a PowerPC board of unknown manufacture.


    On 14 Sep 2005, anj@aps.anl.gov wrote:

    > Whoever told you to look at PPCbug is most likely on the right

    [snip]
    > although I've never created a bootrom for that family. Following
    > the keyword "BOOT" you have the header length of 0x14 bytes, and
    > another number which I can't remember or work out what it's for,
    > maybe a CRC. Starting at offset 0x14 you have the start of a vxWorks
    > ROM image, thus the first word there is a branch instruction to the
    > cold start entry point, and the second word is a branch to the warm
    > start entry point.


    From the limited hex output, this looks like the code from romInit.s.
    From the other posts in this thread, it sounds like the image is
    compressed. The most likely way is to use the pre-canned Tornado
    compression that uses zlib. It is modified to not have a size.

    The compressed image is linked as the last code section afair. So,
    the first part of the file is CPU register setup (MMU, VME, memory
    controllers, etc). The other is the zlib libraries and a limited 'C'
    environment. Clearing zero vars, some 'C' string function, etc.

    I think that the zlib format has some "header"; or a least a
    recognizable beginning. It is typically only one word. This is a
    header from gzip.

    000000 00088b1f 3770ecde 5dec0302 36db936d >....p7..]m.6<
    000010 99d7f692 3f8b815f d3655dac 4ae80778 >.._..?]ex.J<
    ....

    I don't have deflate available to run on a short file. I think it
    will begin with a short sequence. In order to get the decompressed
    image, you can scan forward for the start sequence. I think this is a
    bit mask like "0008FF1F" or something like that. Some of the bits can
    change in the "header". I think the header is actually a record
    header.

    The stock zlib utilities provide library routines you can call. If
    you read the file and scan for this you can interactively try calling
    the zlib and see which "inflate" works. You have to calculate the
    size. I think I did something like this once to determine what
    software a client was using...

    hth,
    Bill Pringlemeir.

    --
    Feynman on QED: I don't understand it. Nobody does.

    vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"

+ Reply to Thread