INT 13h Boot Problems

[~]

How many people have had problems with boot code, by having tried to make it very small and then get read problems, apparently after going to a different track, no matter the delay provided for that?

In other words, a problem due to remove code to make it occupy very few bytes but ending up with a boot code which works in some machines and fails in others.

Also, does anybody know information of BIOS intricacies to have into account (FLAGS changes, register alteration) that have to do with exceptionally fine documentation that could only affect such thing as a boot sector operation, just like "use INT 8 in a loop to turn off floppy"?

Maybe there's a difference in the way that INT 13h works on different BIOS'es that should be known to write low-level "portable" code?

[jerryleecooper]

int 13h? are you talking about the bootloader, or your kernel?
if it's the bootloader, copy your kernel in lowmemory, enable protection, rep movsl to what you like it to be, and jump to it. If it's your kernel, keep it small enough to be able to do the above.
int 13h can't always access low memory even if A20 is enabled. no 0x100000+64k for you on some machine, I suspect it's amd ones.

[~]

int 13h? are you talking about the bootloader, or your kernel?
if it's the bootloader, copy your kernel in lowmemory, enable protection, rep movsl to what you like it to be, and jump to it. If it's your kernel, keep it small enough to be able to do the above.
int 13h can't always access low memory even if A20 is enabled. no 0x100000+64k for you on some machine, I suspect it's amd ones.

The bootloader, the floppy boot sector by now.

I have preferred to copy the kernel to the first Megabyte of memory; the bootloader enters Protected Mode.

Also, I use Unreal Mode to get rid of segment issues; probably that's clearer and less bulky than using otherwise.

It looks like preserving the DX and AX registers just before calling INT 13h and restoring them just after returning from it makes the job.

Code: Select all

            push dx
            push ax
              int 13h
            pop ax
            pop dx

Ralph Brown's Interrupt information said that those registers and the Carry Flag aren't treated the same for all BIOS'es, since some of them destroy such registers.

I have now tested in 2 machines and Bochs and it seems that it was all the problem.

[Jef]

i don't know what exactly you try to do and why you choose unreal mode, but if you entering pmode, try to use only dma and forget the unreal mode.
int 13 is limited.

maybe in the future you will need to do things that no supported by int 13 and you have to rewrite this code using dma.

[~]

It's a standard 512-byte boot sector for FAT12 floppies. It uses Unreal Mode to have a 32-bit-like environment while booting (it seems to be easier to program, forgetting RM segments most of the time).

Finally it fully enables Protected Mode and then jumps to the 32-bit kernel image it copied sector by sector. Each sector is copied at 0x500 and then transferred to a higher address.

---------------------------------------------
Now, here's a problem it has:

- If the keyboard keys are pressed, the process of reading sectors stops.
---------------------------------------------

I looks like it continues reading sectors until after the BIOS flushes the keyboard.

Does anybody know how to prevent the pressing of keyboard from slowing down the load process?

I have seen other OS'es and not one of them seem to have that problem. Also, I haven't found any sign that their boot sectors disable the keyboard. I have already tried disabling interrupts before calling INT 13h, but it won't prevent the keyboard from slowing everything down until its buffer gets emptied, presumably by BIOS.

What should be done? Should the keyboard be explicitly disabled in the boot code and re-enabled when the kernel loads?

[pcmattman]

I don't see any need for the keyboard to be enabled while loading your kernel, as long as it's enabled again once you're done.

[jerryleecooper]

I think your problem, being the kind of problem I like to see in OS development, is that you go in unreal mode. Unreal mode is the culprit. It's not a legit mode, it's more of an hack, prone to problems like the one you mentioned. Wh'at's the size of your kernel? Can you make it smaller?
Tha'ts why there's often second and third stages bootloaders. You can't expect the first bootloader to copy the whole thing into memory at whole.
YOu say you copy sector by sector, but your method, is the whole can of soup.

[Brendan]

Hi,

Now, here's a problem it has:

- If the keyboard keys are pressed, the process of reading sectors stops.

It shouldn't have this problem.

There are some rare things that assume you're in real mode (and not unreal mode) that quietly switch to protected mode, do something and then switch back to real mode (and stuff up your unreal mode segment limits). The BIOS's keyboard handling is *not* one of these things - etherboot is, and there's some obvious BIOS functions (for moving data, etc) that also do this. If you're worried that your segment limits are being messed with, you could restore the segment limits before copying each sector to a higher address to make sure.

IMHO it's much more likely that you trash something you shouldn't. For most BIOSs, if anything causes a GPF the default GPF handler just does an IRET and the CPU re-executes the faulty instruction, causing another GPF (and an endless loop). Most of the BIOS's exception handling is the same (GPF, invalid opcode, etc). For example, if you trash something that the keyboard handling code relies on (like the keyboard's IVT entry) then the keyboard handling code might cause a GPF or invalid opcode (and an endless loop).

@jerryleecooper: While unreal mode is a little undocumented, Microsoft used it for "himem.sys" in DOS for years without problems, I've used it for all my boot code for years without problems, and lots of other people have also used it for ages without problems. I know it works fine on all current 80x86 CPUs and emulators, and IMHO a CPU manufacturer would break too much software to call their CPU "80x86 compatible" if a future CPU didn't behave the same.

@Jef: Using Int 13h means you get ISA floppy disk access, USB floppy disk access, IDE/ATA hard disk access, SCSI hard disk access, emulated floppy/HD ATAPI CD-ROM access, emulated floppy/HD SCSI CD-ROM access and emulated floppy/HD USB flash memory access. If you write your own floppy driver (instead of using BIOS functions) then it's a lot more code and hassles and it'll only work for one device. In the long term, this has additional problems in that end-users may need to install the OS before you they can boot the OS to install it (e.g. you can't have a generic "OS installation boot floppy" that works on all floppy drives, or a generic "OS installation boot CD" that works on all CD drives).


Cheers,

Brendan