Creating a bootp bootable image - 3M?

I am working on creating a bootp ROM for our Network cards (no it is not
available - or even announced - yet - so sHHHH! :sunglasses:
I believe that I have a working prototype, but am having some troubles
with the bootable image file that I am building to try it out.
I can create a bootable image if I keep it small (about 512K max) and use
NBI (tagged image) format, and if I load it into memory within the first
640K.
However, I believe that QNX6.1.0 supports bootable images of up to 3M…
When I try to create one of these (load the image at 1M boundary, and
jump to it) - the system just re-boots.
What is the secret to bootable images over approx 512K??
Can I not jumpto/call the beginning of the image in protected
mode? (necessary to get to the 1M start location)
Do I have to load it in sections, where the first section is below the 1M
boundary - because we are in real mode? If so, how do I tell the startup
code/ifs/whatever where all the sections are?
Should I be creating this image in ELF format? (The boot ROM should be
able to load it into memory if it is in ELF format)
If this forum is inappropriate for this kind of question, who/how/ should
I be talking to??

TIA

Stephen Munnings
Software Developer
Corman Technologies Inc.

In article <MPG.15bfafd9dcce850298969b@inn.qnx.com>, steve@cormantech.com
says…

I am working on creating a bootp ROM for our Network cards (no it is not
available - or even announced - yet - so sHHHH! > :sunglasses:
I believe that I have a working prototype, but am having some troubles
with the bootable image file that I am building to try it out.
I can create a bootable image if I keep it small (about 512K max) and use
NBI (tagged image) format, and if I load it into memory within the first
640K.
However, I believe that QNX6.1.0 supports bootable images of up to 3M…
When I try to create one of these (load the image at 1M boundary, and
jump to it) - the system just re-boots.
What is the secret to bootable images over approx 512K??
Can I not jumpto/call the beginning of the image in protected
mode? (necessary to get to the 1M start location)
Do I have to load it in sections, where the first section is below the 1M
boundary - because we are in real mode? If so, how do I tell the startup
code/ifs/whatever where all the sections are?
Should I be creating this image in ELF format? (The boot ROM should be
able to load it into memory if it is in ELF format)
If this forum is inappropriate for this kind of question, who/how/ should
I be talking to??

TIA

No comment at all?

Not even a re-direct to a better person/place?

\

Stephen Munnings
Software Developer
Corman Technologies Inc.

In article <MPG.15ca1c7eac5f350f98969e@inn.qnx.com>, steve@cormantech.com
says…

In article <> MPG.15bfafd9dcce850298969b@inn.qnx.com> >, > steve@cormantech.com
says…
I am working on creating a bootp ROM for our Network cards (no it is not
available - or even announced - yet - so sHHHH! > :sunglasses:
I believe that I have a working prototype, but am having some troubles
with the bootable image file that I am building to try it out.
I can create a bootable image if I keep it small (about 512K max) and use
NBI (tagged image) format, and if I load it into memory within the first
640K.
However, I believe that QNX6.1.0 supports bootable images of up to 3M…
When I try to create one of these (load the image at 1M boundary, and
jump to it) - the system just re-boots.
What is the secret to bootable images over approx 512K??
Can I not jumpto/call the beginning of the image in protected
mode? (necessary to get to the 1M start location)
Do I have to load it in sections, where the first section is below the 1M
boundary - because we are in real mode? If so, how do I tell the startup
code/ifs/whatever where all the sections are?
Should I be creating this image in ELF format? (The boot ROM should be
able to load it into memory if it is in ELF format)
If this forum is inappropriate for this kind of question, who/how/ should
I be talking to??

TIA

No comment at all?
Not even a re-direct to a better person/place?



Still nothing??

I don’t want this one falling through the cracks…

At least somebody direct me where to go, if this is not the right
forum/method for communicating this issue… Please!

\

Stephen Munnings
Software Developer
Corman Technologies Inc.

Stephen Munnings <steve@cormantech.com> wrote:

Still nothing??
I don’t want this one falling through the cracks…

At least somebody direct me where to go, if this is not the right
forum/method for communicating this issue… Please!

Using the “standard” bios.boot you will load the whole image to
0x400000 (4M) using the extended bios calls (int15 I think). Then
copy down some chunk (say 128-256k) of the image to below 640k and
transfer control to that location in low memory. The .boot (bios.boot)
will figure out where it is, read the information in the image header
you copied down (which includes the entry point for startup-bios), do
some basic MMU futzing and transfer control to startup. If you wanted
to be fancy you could try reading the standard QNX image header (try out
“dumpifs -vv /.boot” sometime) so you wouldn’t be dependant on a
hard-coded load address.

Hope this helps,
chris

\

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Steve,

I’m sitting back anxiously waiting to see if you get it working before
I forge new territory :wink: I went through many painful lessons on QNX4
when sys/boot had issues with being relocated…

Lets talk 3Meg “boot”… The only specification that I am familiar with
that would support this is the Intel PXE spec that would let you d’ld
a “menu” or an initial boot image. If you go with the menu then you
can setup a large download and manage it.

I’ve got PXE running (with ISC dhcp/bootp server) on/for QNX4. Now
that I have an Nto box running at home I’m going to spend some time
setting up at least a <512k Nto PXE boot and start from there.

Only discouraging part is that for all I now know about the QNX4
boot process - sequence, addresses, buildqnx options, … - I know
zip, nada, nothing about the Nto boot process… Yet.

Comments welcome…

Jay

Stephen Munnings wrote in message …

In article <> MPG.15ca1c7eac5f350f98969e@inn.qnx.com> >, > steve@cormantech.com
says…
In article <> MPG.15bfafd9dcce850298969b@inn.qnx.com> >, > steve@cormantech.com
says…
I am working on creating a bootp ROM for our Network cards (no it is
not
available - or even announced - yet - so sHHHH! > :sunglasses:
I believe that I have a working prototype, but am having some troubles
with the bootable image file that I am building to try it out.
I can create a bootable image if I keep it small (about 512K max) and
use
NBI (tagged image) format, and if I load it into memory within the
first
640K.
However, I believe that QNX6.1.0 supports bootable images of up to
3M…
When I try to create one of these (load the image at 1M boundary, and
jump to it) - the system just re-boots.
What is the secret to bootable images over approx 512K??
Can I not jumpto/call the beginning of the image in protected
mode? (necessary to get to the 1M start location)
Do I have to load it in sections, where the first section is below the
1M
boundary - because we are in real mode? If so, how do I tell the
startup
code/ifs/whatever where all the sections are?
Should I be creating this image in ELF format? (The boot ROM should be
able to load it into memory if it is in ELF format)
If this forum is inappropriate for this kind of question, who/how/
should
I be talking to??

TIA

No comment at all?
Not even a re-direct to a better person/place?



Still nothing??
I don’t want this one falling through the cracks…

At least somebody direct me where to go, if this is not the right
forum/method for communicating this issue… Please!

\

Stephen Munnings
Software Developer
Corman Technologies Inc.

In article <9l9ojb$kg5$1@nntp.qnx.com>, cdm@qnx.com says…

Stephen Munnings <> steve@cormantech.com> > wrote:
Still nothing??
I don’t want this one falling through the cracks…

At least somebody direct me where to go, if this is not the right
forum/method for communicating this issue… Please!


Using the “standard” bios.boot you will load the whole image to
0x400000 (4M) using the extended bios calls (int15 I think). Then
copy down some chunk (say 128-256k) of the image to below 640k and
transfer control to that location in low memory. The .boot (bios.boot)
will figure out where it is, read the information in the image header
you copied down (which includes the entry point for startup-bios), do
some basic MMU futzing and transfer control to startup. If you wanted
to be fancy you could try reading the standard QNX image header (try out
“dumpifs -vv /.boot” sometime) so you wouldn’t be dependant on a
hard-coded load address.

Hope this helps,
chris

Well, I haven’t tried it yet, but that is very much the kind of

information that should be very useful… Thanks!


Stephen Munnings
Software Developer
Corman Technologies Inc.

In article <9la9mb$t1j$1@inn.qnx.com>, Jay.Hogg@t-netix.com.r-e-m-o-v-e
says…

Steve,

I’m sitting back anxiously waiting to see if you get it working before
I forge new territory > :wink: > I went through many painful lessons on QNX4
when sys/boot had issues with being relocated…

Lets talk 3Meg “boot”… The only specification that I am familiar with
that would support this is the Intel PXE spec that would let you d’ld
a “menu” or an initial boot image. If you go with the menu then you
can setup a large download and manage it.

Well, AFAIK (especially after reading that reply from Chris - thanks

Chris):

  1. I am using an Etherboot 5.0.0 derived bootp ROM (that is what I am
    primarily working on - for our FE line of cards)
  2. It can load several different loadfile formats.
  3. It runs in a stripped down protected mode, so all physical addresses
    are available to it.
  4. It switches in and out of protected and real mode.
  5. It can load data anywhere in memory, and jump to loaded code in either
    real (<1M only) or protected (anywhere) mode.
  6. It appears that QNX6 startup program needs to be loaded into the lower
    1M, and get control in real mode.
  7. It appears that if the “header information” for the boot file
    specifies an address above 1M that the startup will switch into protected
    mode (it may do that anyway) and process all the remaining code from
    those locations.

This means that my work boils down to the following:
Make/change a program that takes a QNX6 boot file (done by mkifs), and
convert it into an appropriate “tagged” or NBI boot file that the TFTP
process can serve to the network booted machine.
Since the “tagged” format is fairly simple, yet flexible, I should be
able to do what Chris mentioned…
a. Make a tagged “block” that loads at the 4M mark (or wherever the
header says) - for as big as necessary… a complete copy of the boot
file.
b. Take the first xxxK bytes and make it a second block loaded <1M (say
at 0x10000) and jump to the second block in real mode. It appears from
Chris’s commments that the startup code is position independent, and can
handle being started anywhere in real mode memory (that does not conflict
with other software)

I’ve got PXE running (with ISC dhcp/bootp server) on/for QNX4. Now
that I have an Nto box running at home I’m going to spend some time
setting up at least a <512k Nto PXE boot and start from there.

Only discouraging part is that for all I now know about the QNX4
boot process - sequence, addresses, buildqnx options, … - I know
zip, nada, nothing about the Nto boot process… Yet.

This will be a bootp ROM that should work for QNX6 and QNX4.

Only QNX6 will have the ability to boot “large” images - since it appears
to be a thing actually implemented in the QNX6 boot process.
QNX4 boot images will be limited to around 512K or so…

We already have QNX4 boot ROMs for our older cards (FE-120 and FE-130)
but need a new one for our FE-122 card.
I think that with a little re-write of this bootp ROM - replace bootp
with QNX4 native method - that we can create a boot ROM that would work
with all of our FE cards for native QNX4 booting…

So, when all is said and done, we will hopefully have:

  1. A bootp ROM for our FE-??? cards - will do QNX6 and/or QNX4 using
    bootp
  2. A different boot ROM for our FE-??? cards that will do native QNX4
    booting

And maybe, just maybe, if I can figure out a good way to do it…
A single boot ROM that will do either of bootp and native QNX4

Comments welcome…

Jay

Stephen Munnings wrote in message …
In article <> MPG.15ca1c7eac5f350f98969e@inn.qnx.com> >, > steve@cormantech.com
says…
In article <> MPG.15bfafd9dcce850298969b@inn.qnx.com> >, > steve@cormantech.com
says…
I am working on creating a bootp ROM for our Network cards (no it is
not
available - or even announced - yet - so sHHHH! > :sunglasses:
I believe that I have a working prototype, but am having some troubles
with the bootable image file that I am building to try it out.
I can create a bootable image if I keep it small (about 512K max) and
use
NBI (tagged image) format, and if I load it into memory within the
first
640K.
However, I believe that QNX6.1.0 supports bootable images of up to
3M…
When I try to create one of these (load the image at 1M boundary, and
jump to it) - the system just re-boots.
What is the secret to bootable images over approx 512K??
Can I not jumpto/call the beginning of the image in protected
mode? (necessary to get to the 1M start location)
Do I have to load it in sections, where the first section is below the
1M
boundary - because we are in real mode? If so, how do I tell the
startup
code/ifs/whatever where all the sections are?
Should I be creating this image in ELF format? (The boot ROM should be
able to load it into memory if it is in ELF format)
If this forum is inappropriate for this kind of question, who/how/
should
I be talking to??

TIA

No comment at all?
Not even a re-direct to a better person/place?



Still nothing??
I don’t want this one falling through the cracks…

At least somebody direct me where to go, if this is not the right
forum/method for communicating this issue… Please!

\

Stephen Munnings
Software Developer
Corman Technologies Inc.
\


Stephen Munnings
Software Developer
Corman Technologies Inc.

Stephen,

Thanks for the update on Etherboot. The last time I had looked at it
was 3.X and a lot of that stuff wasn’t there.

After you get this together all you’ll be missing to do the QNX4 A-B-C
server stuff is a bootp server that watches the “seconds” since
booting (in the bootp request) and determines if it should answer…

As it just occurred to me - short of doing a static image is there a
way to do a build-on-the-fly image for Nto that specifies the host
name, etc. that is needed?

Jay

Stephen Munnings wrote in message …

In article <9la9mb$t1j$> 1@inn.qnx.com> >, > Jay.Hogg@t-netix.com.r-e-m-o-v-e
says…
Steve,

I’m sitting back anxiously waiting to see if you get it working before
I forge new territory > :wink: > I went through many painful lessons on QNX4
when sys/boot had issues with being relocated…

Lets talk 3Meg “boot”… The only specification that I am familiar
with
that would support this is the Intel PXE spec that would let you d’ld
a “menu” or an initial boot image. If you go with the menu then you
can setup a large download and manage it.

Well, AFAIK (especially after reading that reply from Chris - thanks
Chris):

  1. I am using an Etherboot 5.0.0 derived bootp ROM (that is what I am
    primarily working on - for our FE line of cards)
  2. It can load several different loadfile formats.
  3. It runs in a stripped down protected mode, so all physical addresses
    are available to it.
  4. It switches in and out of protected and real mode.
  5. It can load data anywhere in memory, and jump to loaded code in either
    real (<1M only) or protected (anywhere) mode.
  6. It appears that QNX6 startup program needs to be loaded into the lower
    1M, and get control in real mode.
  7. It appears that if the “header information” for the boot file
    specifies an address above 1M that the startup will switch into protected
    mode (it may do that anyway) and process all the remaining code from
    those locations.

This means that my work boils down to the following:
Make/change a program that takes a QNX6 boot file (done by mkifs), and
convert it into an appropriate “tagged” or NBI boot file that the TFTP
process can serve to the network booted machine.
Since the “tagged” format is fairly simple, yet flexible, I should be
able to do what Chris mentioned…
a. Make a tagged “block” that loads at the 4M mark (or wherever the
header says) - for as big as necessary… a complete copy of the boot
file.
b. Take the first xxxK bytes and make it a second block loaded <1M (say
at 0x10000) and jump to the second block in real mode. It appears from
Chris’s commments that the startup code is position independent, and can
handle being started anywhere in real mode memory (that does not conflict
with other software)

I’ve got PXE running (with ISC dhcp/bootp server) on/for QNX4. Now
that I have an Nto box running at home I’m going to spend some time
setting up at least a <512k Nto PXE boot and start from there.

Only discouraging part is that for all I now know about the QNX4
boot process - sequence, addresses, buildqnx options, … - I know
zip, nada, nothing about the Nto boot process… Yet.

This will be a bootp ROM that should work for QNX6 and QNX4.
Only QNX6 will have the ability to boot “large” images - since it appears
to be a thing actually implemented in the QNX6 boot process.
QNX4 boot images will be limited to around 512K or so…

We already have QNX4 boot ROMs for our older cards (FE-120 and FE-130)
but need a new one for our FE-122 card.
I think that with a little re-write of this bootp ROM - replace bootp
with QNX4 native method - that we can create a boot ROM that would work
with all of our FE cards for native QNX4 booting…

So, when all is said and done, we will hopefully have:

  1. A bootp ROM for our FE-??? cards - will do QNX6 and/or QNX4 using
    bootp
  2. A different boot ROM for our FE-??? cards that will do native QNX4
    booting

And maybe, just maybe, if I can figure out a good way to do it…
A single boot ROM that will do either of bootp and native QNX4

Comments welcome…

Jay

Stephen Munnings wrote in message …
In article <> MPG.15ca1c7eac5f350f98969e@inn.qnx.com> >,
steve@cormantech.com
says…
In article <> MPG.15bfafd9dcce850298969b@inn.qnx.com> >,
steve@cormantech.com
says…
I am working on creating a bootp ROM for our Network cards (no it
is
not
available - or even announced - yet - so sHHHH! > :sunglasses:
I believe that I have a working prototype, but am having some
troubles
with the bootable image file that I am building to try it out.
I can create a bootable image if I keep it small (about 512K max)
and
use
NBI (tagged image) format, and if I load it into memory within the
first
640K.
However, I believe that QNX6.1.0 supports bootable images of up to
3M…
When I try to create one of these (load the image at 1M boundary,
and
jump to it) - the system just re-boots.
What is the secret to bootable images over approx 512K??
Can I not jumpto/call the beginning of the image in protected
mode? (necessary to get to the 1M start location)
Do I have to load it in sections, where the first section is below
the
1M
boundary - because we are in real mode? If so, how do I tell the
startup
code/ifs/whatever where all the sections are?
Should I be creating this image in ELF format? (The boot ROM should
be
able to load it into memory if it is in ELF format)
If this forum is inappropriate for this kind of question, who/how/
should
I be talking to??

TIA

No comment at all?
Not even a re-direct to a better person/place?



Still nothing??
I don’t want this one falling through the cracks…

At least somebody direct me where to go, if this is not the right
forum/method for communicating this issue… Please!

\

Stephen Munnings
Software Developer
Corman Technologies Inc.



\

Stephen Munnings
Software Developer
Corman Technologies Inc.

In article <9lcckv$aga$1@inn.qnx.com>, Jay.Hogg@t-netix.com.r-e-m-o-v-e
says…

Stephen,

Thanks for the update on Etherboot. The last time I had looked at it
was 3.X and a lot of that stuff wasn’t there.

After you get this together all you’ll be missing to do the QNX4 A-B-C
server stuff is a bootp server that watches the “seconds” since
booting (in the bootp request) and determines if it should answer…

As it just occurred to me - short of doing a static image is there a
way to do a build-on-the-fly image for Nto that specifies the host
name, etc. that is needed?

Yes, there is… Haven’t looked into it much, other than to note that it
can be done. (One step at a time - don’t try to run before you can walk!
:sunglasses:
I will be doing this before all is said and done.
(Something like bootpd allows you to run programs on the fly to create
the boot image file that tftp will be serving to the net booted machine)

Jay

snip


Stephen Munnings
Software Developer
Corman Technologies Inc.