Difference IPL and BIOS?

QNX DEVELOPERS Realtime and Embedded
1

Hello all!

I need some clarification on this issue, please. Can someone tell me the difference between an IPL (initial program loader) and the system BIOS on x86 platforms. Are these equivalent or completely different? And is it possible to write an IPL for x86 platforms without having to make alterations to the BIOS?

Some pointers would be extremely useful to me on this subject ;)

Regards,
C++

2

In x86 environment, the IPL is usually loaded by the BIOS. In theory it’s possible to get rid of the BIOS, but in the x86 that is usually lots of working because you may have to “emulated” some of the feature of the BIOS, like PCI resources assignement. Harddisk detection, etc.

3

Hi mario,

thanks for your reply. So the BIOS loads the IPL. Do you have any information how this is done in particular?
Because what I currently need is to implement my own IPL. If I can keep the BIOS, that’s just fine. I only need to write my own IPL, which is then handed over control by the BIOS. Is there any chance I can replace the IPL the x86 machines use by my own one?

Two last questions if I may. Where’s the IPL stored? On a, let’s say easy to write harddisk, etc. or in a hard to program and test ROM chip. And when having an bootable QNX image, it’s the IPL, which is responsible to transfer the image to the RAM, isn’t it? Because that’s exactly the point I need to alter, in order to get the Image to a desired address in RAM, if I’m not mistaken.

Much obliged :slight_smile:

4

This is cover in good detail in the QNX documentation.

Sure

On the device you boot from :wink: Could be floppy, HD, rom, network.

Yes, IPL means Initial Program Loading

If all you want to do is have the image loaded to a perticular RAM address you can specify it in the image. QNX’S IPL will look at that information to decide where to move (or not move in case of XIP) the image.

  • Mario
5

Hi mario,

thanks again for your support.

So when I create the image using mkifs the IPL is created as well? Sorry, but I don’t see 100% clear on this yet.

So let me get this straight. All I have to do is to alter the bootscript in my buildfile in order to get the image to a certain address in RAM?

My current buildfile (bootstrap section) looks like this:

[+compress]
[ //MY ATTRIBUTES, SEE BELOW// ]
[virtual=x86,bios] .bootstrap = {
    startup-bios 
     PATH=/proc/boot LD_LIBRARY_PATH=/proc/boot procnto -vv 
}

So all I have to do is to add … what exactly?
Reading through the documentations of QNX 6.2.1 I’ve found that one can specify

[image=0xXXX]
[ram=0xXXX]
[default_image=0xXXX]
[default_ram=0xXXX]

Please, which one do I need? Because I’ve been experimenting with those a bit. When adding [ram=0xXXX], the system reboots immediately after booting. This can’t be right. The addresses I used are randomly chosen and it doesn’t seem to make any difference.

When adding [image=0xXXX], the system boot normally, but I wasn’t able to find any differences as to where the image went in RAM. Using dumpifs on the image, I got the address of startup_vaddr, that’s, if I’m not mistaken the address in RAM the IPL jumps to when handing over control to the image. Conducting a very simple memory dump at that address, i.e. mapping the memory via mmap_device_memory() and printing it on screen, only brought lot’s of zeroes. So something must be pretty wrong here. Either I’m looking at the wrong address, or mmap_device_memory() is initializing the memory with zeroes. But I don’t believe it’s the latter one.

The attributes [default_image=0xXXX] and [default_ram=0xXXX], as they were stated out in the documentation for the bootscript are rejected all along by mkifs.

Please, can you straighten this out for me a bit, because this is really driving me nuts. I just started out with QNX, everything worked fine so far, only this thing seems to resist doing what I expect it to do.

Much obliged :slight_smile:

6

Hi again,

quick question. Has anyone successfully been able to get the stuff as written on
support.qnx.com/developers/docs/ … g_nto.html
running?

Specifying command-line options to mkifs

As mentioned above, you can also specify command-line options to mkifs. Since these command-line options are interpreted before the actual buildfile, you can add lines before the buildfile. You would do this if you wanted to use a makefile to change the defaults of a generic buildfile.

The following sample changes the address at which the image starts to 64K (hex 0x10000):

mkifs -l "[image=0x10000]" buildfile image

I compiled the buildfile exactly with the command mentioned above. Yet, the system hangs immediately after booting. Am I doing something wrong or what’s happening here? Can I really push the image to that address? Addresses above the 0x300000 seem to work OK. :open_mouth: What’s happening here? The test platform is as mentioned a x86 machine with QNX 6.2.1.

Much obliged :slight_smile:

7

I don’t think 0x10000 is a valid address, because the image will endup in some special area, like video memory 0xa0000 ;-)

8

Hi mario,

thanks for your answer, but unfortunately I have to bother you again with yet another question ;)

Concering the answer on the crash, that’s what I thought too. But why is it then mentioned in the official PDFs this way? Or does it have anything to do with my image being bigger than 576k? If it’s stored in continous memory and I place it at 64k, after 576k I run into trouble, writing to the reserved memory area (640-1024k).

But yet another question mario, if I may. Do you know whether it is possible to clear the first 640k of memory space? Or is this always occupied by the operating system? I know clearing the 640 to 1024k range is a bit hard, that’s where video RAM etc lies. But what happens after the image has been loaded into RAM by the IPL? Is the operating system executed from there or does it alloc memory in the 0-640k range? The filesystem of the image is still in the image, that’s clear. But does QNX Neutrino do anything in the first 640k of RAM? Because whenever I dump the memory of that part of the RAM, there seems to be data stored there. Guesses? Suggestions? Facts? :wink:

Much obliged :slight_smile: