Clemens Buchacher wrote:
Ohhh. I didn't know this. I have only the i386 Programmer's Reference Manual that does not contain this type of info. Do you know if there is a site link with this info?Hi, On Tue, Jul 15, 2003 at 03:44:43PM +0200, Koala GNU wrote:2) Another step is to move the parameters table from 0x78:0 to 0x9000:0x4000-12. WHat are the info contained in this table? Can you send me a link to a site that specify these info?0:0x78 (physical address 0x00078) is really an address to an entry of the Interrupt Vector Table (IVT). Each entry in this table simply consists of a segment:offset pair specifying the entry point of the corresponding interrupt handler. Hence each entry is 4 Bytes long (16-bit segment + 16-bit offset). Interrupt 0x1E (0x78/4 = 0x1E) is an exception to this rule. It contains the address of the so-called Disk Initialization Parameter Table (DPT) Vector. An elaborate book on PC hardware should explain its details.
OK. I am interested on the argument. I have looked at very old code (since it was more simple). My goals were to understand the basic process and then look at the 2.4 code to understand optimizations.So bootsect.S moves 12 bytes from the offset specified at 0x00078 (assuming segment 0?) to 0x93ff4 (right above the recently set up real mode stack). The following code then sets byte 5 (offset 4) of our new DPT to 36, as explained in the comment above the code. Instead of manipulating the original DPT, its address is simply updated to offset %di (0x3ff4) and segment %es (INITSEG=0x9000):movb $36, 0x4(%di) # patch sector count movw %di, %fs:(%bx) movw %es, %fs:2(%bx)I hope that helps. By the way, there is still a line in the bootsect.S code I do not understand. In the kernel sources of version 2.4.18 it is line number 318: # here %cx contains the number of sectors read 312 shlw $9, %cx # %cx * 512 = number of bytes read 313 addw %cx, %bx # bx + bytes_read = new buffer offset 314 jnc set_next_fin # segment overflow? 315 movw %es, %ax # increment %es 316 addb $0x10, %ah # to point to 317 movw %ax, %es # next segment 318 xorw %bx, %bx # reset %bx??? 319 set_next_fin: 340 ret This code segment is part of the set_next procedure, which updates the buffer address (%es:%bx) for successive reads from the diskette. In case of a segment overflow the buffer segment %es is incremented appropriately, while the offset %bx is set to 0, although IMHO it should already contain the correct offset into the next segment. I guess it doesn't really matter, because the number of setup sectors needed for an overflow like that would have to be above 2^(16-9)-1 = 127 sectors, but SETUPSECTS is currently only 4. Still I would like to know whether I am right or wrong. So if there is anybody out there who is interested in discussing the floppy boot-record code, please contact me.
The boot process after the loading of bootsect load the 4 sectors of setup code (I am referring to 2.4.18 kernel). This is done using the routine read_track, that read only the 4 sector, so in this case you are right. But After the loading of 4 sectors the boot process load the kernel using the routine read_it that try to load SYSSIZE byte == SYSSIZE/512 sectors -> on 1.44 floppies is (SYSSIZE/512/18 + 1) tracks. In this case it is clear that we can have 64Kb boundaries overflow.
Looking at very old version of Linux this approach is more clear. I know that a true hacker should look alway at the last version but ......
I agree with you that %bx already contain 0 so I do not have the answer that you are looking for. Probably a more expert guy on this mail list can help us.
with kind regards, Clemens Buchacher -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
