Hello and thanks again
So I get the point. “Hacking” the kernel is not only time expensive, but monetary expensive as well.
Maschoen, believe it or not, but I’m quite interrested in the entire startup procedure of x86 CPUs. So if you have any useful internet pages where the startup procedure is explained in detail, I’d be happy if you can provide me with those URLs
You also mentioned the IPL of the boot loader being in the first 640k of RAM. When browsing through the QNX 6.2 manuals, in the utilities.pdf I found on p.953, that the boot image contains a startup header. Searching through the source files, I also found the bit pattern or the signature of that header. Conducting a memory dump, startup header signature is always found twice in the first 640k of RAM. Do you have any insight, why it is found twice? According to your previous explanations and my memory dump, the image seems to be cut in half and loaded into different sectors of the RAM.
Mario, yes, you may ask why I’d like to move the image at runtime. It’s a long explanation, I hope you don’t mind
Currently I’m working on a memory test. Problem is, that I must test the entire memory space, or at least as much as possible. So if I have an image located at address 0x400000 +1024k, I can’t test those 1024k, which is why I have to move it. Now I’ve come up with 2 strategies. Either move the image at runtime, or conduct a reboot and place the image at another address then. As I’ve learnt, I can most certainly forget the first choice, which is why I’m focussing on a double boot strategy right now. That was also the case (@mario), why I was eager to place the image at a particular address in the RAM in the other thread I opened in this forum.
The only problem I now have is to come to terms with the first 640k of RAM, because they seem to be kind of special. So if any of you has specific information what QNX puts in there exactly, I’d be very happy. Therefore the question, after the image is loaded into RAM, does anything get extracted and moved to other memory locations, or does QNX operate solely within the image? But to be honest, I don’t believe this, because processes that get started right after booting the system most certainly need some kind of memory to run.
If anyone of the two of you can confirm to me, that QNX Neutrino tests the memory it occupies itself before it starts up, that would be good news as well.
Now you might ask, why I simply don’t use Memtest86 for this endeavour. Good question. Problem is, that the customer likes to have a logfile written to hard disk or any other permanent storage device. Unfortunately Memtest86 doesn’t allow this. It can test the entire RAM, except reserved RAM space, like the 640 to 1024k area. It can also relocate itself at runtime, which is why I thought QNX can be tought to do the same. But it runs completely without operating system support, which means no file system, no system calls, no nothing. Writing a logfile under these circumstances is a bit hard I suppose, but it’s a second option I currently follow. If you have any alternatives I haven’t considered so far, please let me know. Because right now it seems that QNX is giving me too much, Memtest86 too little
So, having gotten the information you provided to me, what I’d like to know in order to continue is whether the QNX operating system tests RAM it occupies itself. How does the first 640k of RAM look like in QNX specifically? And is there an easy way to do an automated reboot, selecting the second image being started.
What I have in mind is the following. 3 images:
1st: Placed at address 0x400000 (testing RAM, minimal image)
2nd: Placed at address 0x600000 (testing RAM, minimal image)
3rd: Placed at default RAM address (normal image, applications, etc.)
Correct me if I’m wrong, but under Linux the kernel image lies under /proc/boot/ Would it be sufficient to, after the first image is done, to swap the 1st and the 2nd image under /proc/boot? Or isn’t it that easy?