Where in memory does an EL-Torito bootsector end?

[Isaac]

A regular 512-byte bootsector starts at 0x7C00 and ends at 0x7E00. But where does an EL-Torito bootsector start and end at? Since it's 2 KB long, if it also starts at 0x7C00 it would have to end at 0x8400. Is that the case?

[Nable]

A regular 512-byte bootsector starts at 0x7C00 and ends at 0x7E00. But where does an EL-Torito bootsector start and end at? Since it's 2 KB long, if it also starts at 0x7C00 it would have to end at 0x8400. Is that the case?

I think that wiki doesn't contain wrong things, at least in this article: http://wiki.osdev.org/El-Torito#What_Next.3F
You can find answers there. I can even copy some quotes here:

[ORG 0x7C00]

After you have done the 'normal' boot sector jobs, such as setting segment registers to known values and saving the contents of DL (which contains the BIOS boot drive number), you can start reading the file system, in the 2k that you have available in your boot sector.

[Brendan]

Hi,

A regular 512-byte bootsector starts at 0x7C00 and ends at 0x7E00. But where does an EL-Torito bootsector start and end at? Since it's 2 KB long, if it also starts at 0x7C00 it would have to end at 0x8400. Is that the case?

For El-Torito; the CD has a "Boot Record Volume Descriptor" (in sector 10) that points to a "Boot Catalogue". The Boot Catalogue contains an unlimited number of entries. The firmware scans these entries to find a suitable "section entry" for the computer (e.g. same platform, and possibly other criteria like language/locale). This entry includes the starting LBA address, the number of (virtual, 512-byte) sectors, and the load segment (it doesn't have to be 0x07C0:0x0000).

For "no emulation" El-Torito, the firmware loads however many (virtual, 512-byte) sectors from the starting LBA address that the section entry said. Basically; it doesn't load a boot sector, it loads a "boot file" that may be 1 or more sectors (up to 0xFFFF virtual 512-byte sectors; or up to 32 MiB).

Of course on 80x86 you can't really boot a file that is larger than the memory available. For example, you could set it up as "load segment = 0x0100, number of sectors = 1264" to ask the firmware to load the boot loader from 0x00001000 to 0x0009EFFF and have a 632 KiB boot loader; but anything larger than that will probably trash the EBDA and cause problems. Note: It's possibly better to use "load segment = 0x07C0" in case the BIOS is buggy.

For "hard disk emulation" or "floppy disk emulation" El-Torito, it just emulates the hard disk and floppy disk (including the "only load a single measly 512-byte sector" thing that makes us all sad ). This also sucks for other reasons and is mostly there for crusty old OSs that don't support booting from CD at all (e.g. MS-DOS).


Cheers,

Brendan

[freecrac]

Hello.

This also sucks for other reasons and is mostly there for crusty old OSs that don't support booting from CD at all (e.g. MS-DOS).

But with third party software it is possible to encrust and to brighten MS DOS and to make a MS-DOS Boot-CD and/or a MS DOS USB-Stick that can boot MS-DOS from the Stick or from a CD.

This way is open and without a protection for MS DOS there are no impenetrable walls that can block it. So i think the crust of modern OSses that use the protected mode is more massive and more fully grown and in opposite to the thin dermic like a transmissible film of the MS DOS butterfly.

Dirk

[Octocontrabass]

But with third party software it is possible to encrust and to brighten MS DOS and to make a MS-DOS Boot-CD and/or a MS DOS USB-Stick that can boot MS-DOS from the Stick or from a CD.

...Which boots using the floppy disk or hard disk emulation provided by the BIOS, since DOS is only compatible with floppy disks and hard disks.

At least with El Torito, it's easy to tell the BIOS which emulation mode you want.

[Isaac]

So, how do I know what the load segment is?

Where can I find a map of how memory looks after booting from a CD-ROM?

[sortie]

Isn't there an El-Torito specification that covers stuff like this?

[Isaac]

Where can I find this "El-Torito specification that covers stuff like this"?

[sortie]

Do basic online searching, okay? Nable linked to the wiki article on El-Torito. Scroll down to external links, there are some links to what looks like specifications for El-Torito. That is probably a pretty good start. Perhaps you can find more accurate and up to date information on Google? I haven't read the specification, but I would imagine it is freely available online. Let us know if you fail to locate it, after you have actually done a real effort.

[shikhin]

Hi,

So, how do I know what the load segment is?

You specify the load segment in the bootable ISO you generate. Depending on the tool you're using to do so, I think it should be safe to presume it's 0x07C0.

Where can I find a map of how memory looks after booting from a CD-ROM?

The Wiki provides a good memory map of low memory; the only difference with booting from a CD-ROM is that the bootloader occupies the area you specify in the ISO.

Regards,
Shikhin

[Isaac]

I wrote a little ISO 9660 (El-Torito) bootfile. Here is the code:

Code: Select all

BITS 16
[org 0x7C00]
start:
mov ah,0xe
mov al,'F'
int 0x10
mov al,'S'
int 0x10
jmp $
times 2048-($-$$) db 0

It's supposed to print an "F" (stands for "First" letter) and then an "S" (stands for "Second letter"). But then I assembled it with NASM, made an image out of it using Genisoimage, ran it using QEMU and it only printed an "F"! Why?

[Nable]

Why?

It looks like that kind of self-exercises that are sometimes called 'homework' here. Ok, I should answer something helpful then.

You initialize 'AH' before the first call but don't do it before the second. Can you refer to some specification that tells that 'int 0x10' must preserve AH or you just assumed it? Assumption is almost never a good thing, so if something isn't declared in specification it's good to be prepared for some bad cases.
Btw, I would recommend you to try built-in debugger of Bochs or QEmu. They are very nice for inspecting situations when something goes wrong.
I can also add that you don't initialize BX register, although this 0xE call uses it as an input (see http://wiki.osdev.org/RBIL -> http://www.ctyme.com/intr/rb-0106.htm).

[Combuster]

Start with initializing a stack before using it.

[Isaac]

I'm pretty sure that int 0x10 preserves AH. But just to make sure, I tested it out.

Code: Select all

BITS 16
[org 0x7C00]
start:
mov ah,0xe
mov al,'F'
int 0x10
mov ah,0xe              ; this is the line I added
mov al,'S'
int 0x10
jmp $
times 2048-($-$$) db 0

I got the same results; only the first letter was printed to the screen. I also tried setting up the stack:

Code: Select all

BITS 16
[org 0x7C00]
start:
mov bp,0x9000        ; I added these
mov sp,bp              ; two lines
mov ah,0xe
mov al,'F'
int 0x10
mov al,'S'
int 0x10
jmp $
times 2048-($-$$) db 0

But now it doesn't print anything. That's even worse than before! So, does anyone know the cause of the problem?

[Nable]

Code: Select all

BITS 16
[org 0x7C00]
start:
mov bp,0x9000        ; I added these
mov sp,bp              ; two lines

But now it doesn't print anything. That's even worse than before! So, does anyone know the cause of the problem?

You've initialized stack pointer but didn't set stack segment register.
And you still didn't use debugger, did you?