Booting from CD but... what's going on with floppy boot?

[Whitebird]

Hello everyone!

I'm developing an OS that have pmode enable, but uses segmentation and runs bellow 1mb.

Everything is going fine: I've a bootloader that enables pmode, and load a C kernel. I've already have the GDT, IDT, IRQs ISRs, some system calls and even an primitive keyboard driver....

I'm debugging everything in Virtual Box and once in a while, when a last stable build is ready, I burn some floppys and CDs and test the hole system on a real machine.

But I had some troubles in last build (I was working on system memory):

Everything works fine when I'm running my OS in Virtual Box or in a real machine booted with CD. But when I test it booting with floppy, the "load sector function" enters into a inifite loop and don't load anything or much less jump to kernel address's.

Anyone have an idea what is going on?

Thank.

[xenos]

It would be much easier to locate the problem if you could provide the relevant part of your code (i.e., the boot loader).

[Whitebird]

Ok here it is:

Code: Select all

;==========================================NASM HEADERS=============================================

%define KERNEL_SEG 0x0000 ; kernel segment
%define KERNEL_OFF 0x7E00 ; kernel offset
%define KERNEL_SIZ 40     ; kernel size (into sectors of 512 bytes)
%define KERNEL_SEC 2      ; kernel sector
%define KERNEL_CYL 0      ; kernel cylinder
%define KERNEL_HEA 0      ; kernel head

%define STACK_ESP 0xCDFF 
%define STACK_EBP 0XCDFF

;==========================================NASM HEADERS=============================================

[BITS 16]

org 0x7C00                    ; ip = 0x7C00
jmp start                     ; cs = 0x0000

start:
    mov [drive],dl            ; store current drive number
    xor ax, ax 
    mov ds, ax                ; ds = 0x0000

;set up video mode 
    mov     ah, 00h           ; subfunction: set video mode
    mov     al, 03h           ; 0x03 = 80x25, 16 colors
    int     10h               ; interrupt: video

; Reset the Floppy Drive
reset:            
    mov ax, 0x00              ; subfunction: reset
    mov dl, [drive]           ; drive number
    int 0x13                  ; interrupt: drive
    jc reset

; Load Kernel at es:bx

    mov bx, KERNEL_SEG
    mov es, bx
    mov bx, KERNEL_OFF
    mov ah, 0x02              ; subfunction: read
    mov al, KERNEL_SIZ        ; number of sectors that will be read
    mov cl, KERNEL_SEC        ; sector
    mov ch, KERNEL_CYL        ; cylinder
    mov dh, KERNEL_HEA        ; head
    mov dl, [drive]           ; drive

; HERE IS THE PROBLEM
read:

    int 13h                   ; interrupt: drive
    jc read

lgdt [gdtr]                   ; load gdtr. ATENTION DS MUST BE EQUALS TO 0x0000

cli                           ; disable BIOS interrups

; Set Protected Mode
mov eax, cr0         
or  eax, 1   
mov cr0, eax

jmp dword codesel:pmode       ; Enter Protected Mode

[BITS 32]

; Load Segment registers with 32 bit Selectors
pmode:                                                      
    mov eax,datasel
    mov ss,eax
    mov ds,eax
    mov es,eax
    mov fs,eax
    mov gs,eax 
    mov ax,0x10
    mov ss,ax
    mov esp,STACK_ESP         ; maxmimum
    mov ebp,STACK_EBP         ; maxmimum
    mov dl,[drive]            ; we want to know what drive in
    
    push dx

jmp dword codesel:KERNEL_OFF  ; jump to kernel  

;============================================VARIABLES==============================================


; Global Descriptor Table Register
gdtr:
    dw gdt_end-1
    dd gdt

; Global Descriptor Table Descriptors
gdt:
    nullsel equ $-gdt   ; null descriptor
        dd 0
        dd 0

    codesel equ $-gdt   ; kernel code descriptor
        dw 0xFFFF
        dw 0x0000
        db 0x00
        db 10011010b    ; access byte
        db 11001111b    ; flag and hi limit
        db 0x00

    datasel equ $-gdt   ; kernel data descriptor
        dw 0xFFFF
        dw 0x0000
        db 0x00
        db 10010010b    ; access byte
        db 11001111b    ; flag and hi limit
        db 0x00
gdt_end:

; Drive Number
drive db 0                           

;============================================VARIABLES==============================================

;=========================================NASM DIRECTIVES===========================================

; fill the end of sector with signature's boot
   times 510-($-$$) db 0
                    dw 0xAA55

;=========================================NASM DIRECTIVES===========================================

[DavidCooper]

I don't think it's possible to load sectors from more than one track at a time when using a floppy disk - there may even be a difficulty loading more than one side at a time on some machines, so I load 17 sectors (2 to 18) from track 0 head 0, then 18 sectors from track 0 head 1 on the next int 13h call, and so on.

One small detail you might want to change is your stack address which should be a byte higher than you've put it - it won't write to the address you set it to, but to the two/four below that instead, so all your stack data will be badly aligned and slow down the running of your code.

[Chandra]

I don't think it's possible to load sectors from more than one track at a time when using a floppy disk - there may even be a difficulty loading more than one side at a time on some machines, so I load 17 sectors (2 to 18) from track 0 head 0, then 18 sectors from track 0 head 1 on the next int 13h call, and so on.

True. This exactly is your solution.

[Brendan]

Hi,

I don't think it's possible to load sectors from more than one track at a time when using a floppy disk - there may even be a difficulty loading more than one side at a time on some machines, so I load 17 sectors (2 to 18) from track 0 head 0, then 18 sectors from track 0 head 1 on the next int 13h call, and so on.

Floppy hardware is worse than that, as the chance of (intermittent) read errors is relatively high. If there's a 90% chance that reading one sector will work without needing a retry, then for 18 sectors you get "90% * 90% * 90% ...." which works out to a 15% chance that reading 18 sectors at once will work without needing to be retried.

Floppy disks also tend to have a high chance of permanent failures. To tell the difference between an intermittent problem and a permanent problem the normal advice is to do 3 attempts with a "reset disk system" call in between. In my experience this is excessive, and the "reset disk system" call causes an expensive recalibrate/seek that could be skipped for the first (and maybe second) retry.

If there is a permanent failure, you should tell the user there's a permanent problem (and what the problem is, if you can). Attempting to destroy the user's floppy drive (by pounding the daylights out of it forever) just because they were unlucky enough to use bad media isn't a good idea.

You can combine all of this. The best approach I've ever seen is to begin by attempting to read full tracks. If there's any failure on the first attempt then increase a "full track failure count" variable and use single-sector reads for that track instead. If the "full track failure count" variable is below a certain threshold (e.g. 4) then continue to attempt to read full tracks, otherwise use single-sector reads without even attempting to read the full track first. For the single-sector reads, I try it once, then try it again, then reset the disk system and try it 2 more times (then decide it's a permanent failure and display a "Can't boot because..." error, and do HLT in a loop until the user resets the computer).

For "boot from CD", I wouldn't use floppy emulation to begin with.


Cheers,

Brendan

[Whitebird]

Thank you guys for replying me!

I'll take your advices and work on bootloader for treat this problems!
Then, if everything goes wrong again I'll post here again.... (hope don't)

Brendan I became curious: how do I boot my system from a CD without using floppy emulation?

[iocoder]

"how do I boot my system from a CD without using floppy emulation?"

I do it using EL-TORITO "no emulation", with GRUB.
EL-TORITO: http://wiki.osdev.org/El-Torito
How to make a bootable EL-TORITO CD with GRUB: http://wiki.osdev.org/Bootable_El-Torit ... RUB_Legacy
Good Luck !

[Whitebird]

But how do I do it without using GRUB? I'm using my own bootloader =]

[Tosi]

Read the El-Torito article and skip the one on GRUB.

[Chandra]

But how do I do it without using GRUB? I'm using my own bootloader =]

Use 'Int 13h Extensions'.

[Brendan]

Hi,

But how do I do it without using GRUB? I'm using my own bootloader =]

Quick summary:

• Read the ISO-9660 file format to get yourself familiar with how that works
• Read the El-Torito spec, to understand how that works (and find the format of boot records, etc)
• Implement something that creates an ISO9660 disk image (including directory structures, path tables, boot record, etc). I do this with NASM because I'm lazy (and because NASM's macros are powerful enough and the ISO9660 format is simple enough), but it'd be easy enough to slap together a utility in C or something to do it.
• BIOS is meant to load a file (your boot loader) at whatever address you tell it
  • use 0x7C00 as the load address to avoid bugs in buggy BIOSs that don't support other load addresses properly
  • In theory, your boot loader can be large (500 KiB or something), and there's no partition table or BPB or anything else in it.
• Boot loader needs to find other file/s on the CD. Search the path tables to find the sector number of the right directory, search the directory to find the sector number of the right file. There's no fragmentation or anything to worry about for ISO9660 - everything is stored as contiguous sectors. If your boot code does load multiple files, put them all in the same directory (e.g. "/boot") and cache the directory information so you don't need to re-read it (or the path table) for each file.
• Use 'Int 13h Extensions' to load sectors from CD (BIOS will tell you which device number in DL). Sectors are 2 KiB, not 512-bytes.

Floppy emulation sucks for 2 reasons. First, even for 2880 KiB floppies (and even with compression), there isn't really enough disk space to do a good job (e.g. modern monolithic kernels for x86 are about 5 MiB; a micro-kernel plus all the drivers, etc would be just as large; and a simple splash image can be 1 MiB or more). To get around that, most boot floppies are cut down versions of the OS (e.g. just enough to download the rest from HTTP/FTP or CD or something), which is easily avoided when you actually are booting from a (about 650 MiB?) CD.

Second, because the underlying sectors are 2 KiB, for floppy/hard disk emulation when you load one 512-byte sector the BIOS has to load 2 KiB and discard 75% of it. There's differences in the way data is stored on CD too (a big spiral rather than tracks) which can make software that is OK for floppy cause excessive (expensive) seeks on CD. Basically anything designed for floppies (and 512-byte sectors) is going to cause an unnecessary performance issues on CD.


Cheers,

Brendan

[octavio]

prueba

[octavio]

Hi,

[*]In theory, your boot loader can be large (500 KiB or something),

Brendan

On the computers i have tested, there is a 64KB limit and it must be loaded in the first 640KB of memory.I was used to load my kernel this way when it was smaller enought, now it has about 90KB in size.The floppy disk emulation is a aceptable solution for small systems ,and it has the advantage that is posible to do (i did) a disk image able to boot from fd,cd,usb,hd etc...