basically, with zImage bootsect.S code moves itself from 0x7c00 location to 0x90000 location and then loads setup.S code at 0x90200 location. After that bootsector code only loads kernel image [zImage] at 0x10000 location and then it transfers the control to setup.S code. setup.S code then moves zImage from 0x10000 to 0x1000 [where firmware code was earlier] and transfers the control to zImage [at 0x1000] after changing to protected mode. In case of bzImage, bootsector code loads setup.S at the same location [0x90200] and then loads bzImage also at the same location [0x10000], but simultaneously using bootsect_kludge function this bzImage is moved to 0x100000. After transferring the whole bzImage to 0x100000, control is transferred to setup.S as usual and then setup.S changes to protected mode and transfers the control to bzImage at 0x100000. bzImage's head.S then decompresses the kernel at 0x100000 only. I think that the above explaination is correct barring one thing that who takes care of the fact that decompression routine itself is not overwritten by the uncompressed kernel. One more question here is, if you see at the starting of bootsect.S, you'll find the following comments :- NOTE! currently system is at most (8*65536-4096) bytes long. This should be no problem, even in the future. I want to keep it simple. This 508 kB kernel size should be enough, especially as this doesn't contain the buffer cache as in minix (and especially now that the kernel is compressed :-) Here, I don't understand why we are taking (8*65536 - 4096) as the size of current kernel. Because if you see the boottime memory layout as mentioned in "Documentation/i386/boot.txt", you will find that actually it should be (9*65536 - 4096), because our bootsect.S starts from 0x90000 and the memory area before 0x1000 is reserved for MBR, BIOS and similar stuff. So actually, we have memory available from 0x1000 to 0x90000, which concludes to [9*65536 - 4096] bytes for system size. Anyone please suggest me why the factor of 8 is there instead of 9 and the details of bzImage more deeply. TAI. Sumit Sharma, IBM, Bangalore. On Wed, 22 Sep 2004 manish regmi wrote : >> ok fine. But if kernel is loaded at 0x100000 and then deompresstion routine >>[head.S] decompresses the kernel at 0x100000 only, there is a possibility of >>overwriting the decompression routine's code by that of the decompressed kernel, >>as both are happening at the same place...so what about that ? >> >>Thanks. >>Sumit Sharma. >> > >exactly, >But you can see in head.s, there is code for moving something to 1000 for bzImage. >frankly i did not understand how. so i called it magic code.. > >regards manish > >_________________________________________________________________ >Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail >
