question regarding IPL, OS image, and socket image

Another possibly dumb question:

I am setting up a NON-bios x86 system with QNX 6.1 / Momentics with
BSP 6.2.0.

I have written IPL and startup code, and I have OS images.
The question is: how does one get the IPL and the OS image (which
should contain the custom startup since it’s refernced in
the build file) into the same socket image?

Is it a matter of doing something similar to
mkimage -o socket.image ipl.bin system.img?

When you use the “buildrom” script in the IPL
directory, it puts the IPL code at an appropriate
place in the ROM, and puts the appropriate opcode
at the reset vector so that the IPL is executed.

How does one do the equivalent when one needs
to put both the IPL and the compressed system
image into one image?

Thank you.

Rich

Richard Bonomo,6289 Chamberlin,263-4683, wrote:

Another possibly dumb question:

I am setting up a NON-bios x86 system with QNX 6.1 / Momentics with
BSP 6.2.0.

I have written IPL and startup code, and I have OS images.
The question is: how does one get the IPL and the OS image (which
should contain the custom startup since it’s refernced in
the build file) into the same socket image?

No such thing as a dumb question, but this is a simple one to answer.

The answer is the mkimage utility.

eg.

mkimage -o socket.img file.ipl file.ifs

This essentially concatenates the files.

Rennie

Rennie Allen wrote:

Richard Bonomo,6289 Chamberlin,263-4683, wrote:

Another possibly dumb question:

I am setting up a NON-bios x86 system with QNX 6.1 / Momentics with
BSP 6.2.0.

I have written IPL and startup code, and I have OS images.
The question is: how does one get the IPL and the OS image (which
should contain the custom startup since it’s refernced in
the build file) into the same socket image?

No such thing as a dumb question, but this is a simple one to answer.

The answer is the mkimage utility.

eg.

mkimage -o socket.img file.ipl file.ifs

This essentially concatenates the files.

Rennie

Dear Rennie (and anyone else who may care to chime in):

Trying to get the details worked out:

If I make a ROM image test ipl using the buildrom script, it calls mkrec
twice (for some reason): once to pad the newly made ipl-bin to 32k (?), and
again to pad it out to 128k and add the reset vector jmp instruction.

If I load that image onto a PROM, the system starts executes the “IPL”
(really a test program) just fine. Examining the image with a hex editor
clearly reveals the jump instruction, and the location of the “IPL” machine
code, right where it needs to be.

What I am trying to do now is produce a PROM image which has the IPL,
Startup code, and OS image.

What I have tried so far is to call mkrec on ipl-bin to produce a 4k image
with a reset vector. Then I used mkimage to produce the socket image
with the IPL and the OS image (containing the reference to the startup
progam). I think I invoked it thusly:

mkimage -s(b?) 512k -o emb.img ipl.img testos.img

This readily produces a 512k image, but it claims it cannot
recognize the “type” of ipl.img (made with mkrec), and I do
not see the jmp instruction that I expect to find pointing to
the start of ipl.img.

I suspect I am missing a number of things obvious to the experienced…

Words of Wisdom, anyone?

Rich

Ah, I finally stumbled across the documentation on
“making multiple images,” and realized that this
applies to me…

Rich

Richard Bonomo,6289 Chamberlin,263-4683, wrote:

Ah, I finally stumbled across the documentation on
“making multiple images,” and realized that this
applies to me…

Rich

Also, I think you made an error in running mkrec on the image before
concatenating with the other components. What you want to do is merge
everything into a big blob (using mkimage), and then run mkrec on it; as
all mkrec does is take the binary and convert it into a format used by a
programmer (in the end it’ll end up being a binary image again).

The reason mkimage said it couldn’t recognize the image file system is
that it had been converted to srecs (or something) prior to assembling it.

Rennie