Barry (who you’ve been corresponding with directly) has been
discussing this with me as well…
KenR <firstname.lastname@example.org> wrote:
Im using a ZFmicro ZFx86 processor. Its a fully 386 compatable(or so they
claim) CPU designed for embedded systems. Im booting from flash but the
kernel doesnt want to execute as it should. I have purchased and read the
embedded toolkit but still
Heres the basic steps from the
beginning of what Im doing:
1)Ive written a optional bios extension routine to copy the os image
(.boot file) from flash to memory location 0x100000 1MB) This routine puts
the system in flat-real mode(go to protected mode, setup gdt to access 4gig
memory space, return to real-mode.
Presumably you’ve done step 1 because your hardware uses paged flash, correct?
In a system with linear flash, it’s not necessary to copy the image
before executing image_scan_ext(), as it is capable of reading directly
from flash, even flash which is mapped above 1M.
So, at this point, you’ve got a linear boot image in memory at 1M.
2)Ive written an QNX IPL and loaded it as an optional bios extention.
Here is where everything screws up. Im now going to explain on a low level
what Im doing and the results.
image = image_scan_ext (0x100000, 0x101000);
and it finds the image at 0x100400.
Good so far…
Then im using
and it returns no errors but it seems like its copying the kernel to
0x400000 4MB in memory.
Actually, image_setup_ext only copies the preboot header, the startup
header, and startup; it leaves the rest of the image where it is.
In the past, image_setup_ext would copy these items based on the
address specified in the build file [image = 0x…]. It was
necessary for this address to be below 1M, and to allow the largest
image possible, you would normally specify [image=0x10000]. However,
this still limited you to a boot image which was less than 640k,
uncompressed. Any larger than that, and the image would ultimately
overwrite the BIOS data area.
When startup was modified to allow x86 boot images greater than 1M
in size, the BIOS extension IPL code was also modified. Now, an
address greater than 1M can be specified in the build file, for
example, [image=0x400000]. When image_setup_ext runs, it examines
this value, and if it’s greater than 640k, the startup header and
startup get copied instead to 0x4000.
So when the image_start_ext is executed a real-mode
segment and offset is calculated from an address above 1MB which is not
image_start_ext() also calculates the segment and offset based on
the 0x4000 address, not on the address above 1M.
When startup executes, it takes care of copying the image from
where it’s currently sitting (in your case, in memory at 1M) to
it’s final run address, which is the value specified in the
build file. If the image is compressed, it gets de-compressed
along the way.
if I put the line
[image=64k] in my image build file, the system resets when I do the
this is probably because your image is being copied / decompressed
into the BIOS data area. You should specify [image=4M] or some other
address above 1M in your build file (however, don’t specify near the
area where your initial BIOS extension is copying the image from flash
I mentioned earlier that the BIOS extension IPL was modified to
accomodate the new ability to use boot images larger than 1M. However,
the ipl library did not get updated in time for the last release, so
an updated libipl.a for x86 was posted on our web site. This updated
lib contained the fixes described above, as well as a fix to the
int15_copy() function, which the IPL routines use. I’m told by Barry
that you’ve downloaded this lib, and your previous int15_copy() reboot
issues are now resolved. However, if you’ve copied the image_setup_ext()
or image_start_ext() functions from their home in the source tree to
your local IPL directory (perhaps to insert debug info), and then built
your IPL, you’ll be overriding the modified IPL functions with the old
versions that you have.
Has anyone had any similar problems or experiences. This is urgent and I
would appreciate every little bit of input.
Thanks is advance
Best of days
Dave Green (email@example.com)
QNX Software Systems Ltd.