OSDev.org

scdbackup wrote:i have to contradict BenLunt's understanding of El Torito Sector Count
(aka Load Size). The counting unit is 512, not 2048.

Hi Thomas,

When in emulated mode, I believe the (virtual) sector size is 512 bytes. Therefore, a count of four will load four emulated 512-byte sectors, which is one CD sector of 2048.

When in non-emulated mode, with a count of four, will it load four CD sectors of 8192 bytes or four 512-byte sectors of 2048 bytes?

In my opinion, I have not tried it yet though it would be a simple task to do so, when in non-emulated mode, a count of four will load four 2048-byte sectors for a total of 8192 bytes.

The way I take it, when in non-emulation mode, the BIOS should load the count of sectors to the segment given and jump to it, period. Again, in my opinion, Virtual Sectors are only used in emulation modes. When in non-emulation mode, sectors are 2048 bytes each.

A count of four, whether in emulation mode or non-emulation mode will have no ill effect when all you need is the first 2048 bytes. When in emulation mode, a count of four will load four emulated (virtual) sectors, a count of 2048 bytes. When in non-emulation mode a count of four will at the very least load the first 2048 bytes. The remaining 6144 bytes loaded will have no ill effect on the system since nothing should be at offset SEG:0x0800 anyway.

This is what I got from the specification and have seen used, but is just my findings, mostly from memory too.

Ben

Hi,

El Torito specs say that Sector Count is the number of "virtual/emulated sectors"
and that "virtual sectors" have 0x200 = 512 bytes.

mkisofs man page says: In the mail where the developer of ISOLINUX confirms the rumors about
"4 blocks good, more blocks bad", he does not contradict the original posters
computation "4 * 512 byte".
http://www.syslinux.org/archives/2003-S ... 02559.html

Have a nice day

Thomas

Hi,

glauxosdever wrote:I tend to disagree. Booting from floppy but actually loading the system from cdrom is an ugly solution, possibly even more ugly than the Boot Information Table. In the former case, there is much hassle for the end-user. In the latter case, you won't have any problems, unless you support building with different tools for the same task.

For old computers (e.g. the 80486 I had, where El Torito didn't even exist when the firmware was written); which of these options do you think is "less ugly" for the end user:

• It's impossible to boot/install the OS
• You need a set of many floppy disks, where running the OS directly from many floppies is completely impractical, and installing the OS from many floppies involves prompting the user to change floppy disks many times ("Please insert disk #12 to continue installing").
• Expect the end user to remove the hard drive and plug it into a different computer, and provide a kind of "cross installer" (e.g. that bypasses the normal "autodetect what needs to be installed" stuff because the computer the OS is being installed on is different to the computer the OS going to be booted on).
• Put a floppy disk image on the installation CD so that the end user can create a boot floppy (on any OS, on any computer); where that boot floppy contains a minimal version of the OS with little more than CD drivers; where the user boots from floppy and everything else needed to boot or install the full OS comes from the CD.

Note: If you don't care about ancient computers (that may not support El Torito at all), then you probably have no reason to care about ancient computers (where El Torito exists but is buggy) either.


Cheers,

Brendan

I had to write a small test app to check.

My test app would simply boot from the CD in non-emulation mode, then print the first 16-bit word from each 0x0200 offset until an unknown value was found.
Noting that I hard coded the remaining sectors to have this value.

For example:
1. The first sector (offset 0x0000) does not need to have a magic number. If the BIOS didn't read the first sector, we can't run the boot app .
2. The second (512-byte) sector, offset 0x0200, has a value of 0x0200.
3. Each remaining (512-byte) sector has its corresponding value as the first word.

offset 0x0200 = 0x0200 (relative to 0x07C00)
offset 0x0400 = 0x0400
offset 0x0600 = 0x0600
...
offset 0x1E00 = 0x1E00 (sixteen 512-byte sectors)

My app would simply do: I tried it with the Load Sector Count equal to 2 and tried it on two older (late 1990's) machines. Both printed:
0000
0200
meaning that the BIOS on both machines loaded two 512-byte sectors.

I then tried it with the Load Sector Count equal to 8. Both printed:
0000
0200
0400
0600
0800
0A00
0C00
0E00
Both loaded eight 512-byte sectors.

Note: This assumes that the memory at 0x07C00 and every 0x200 offset after does not already contain that value, which is very unlikely it would anyway after a reboot.

So, my findings (which proves my previous points false) the BIOS is to load a count of 512-byte sectors no matter the emulation mode. My bad. Sorry.

Also, for the original poster, both BIOSes loaded more than 4 sectors. At least these two do anyway.

Ben

Hi,

BenLunt wrote: BIOS is to load a count of 512-byte sectors no matter the emulation mode.

The majority of implementers on both sides on the interface understand
it that way. (I am just a neutral bystander.)

A BIOS implementer who understood 1 block = 2048 bytes might even be the
origin of the cautious habit (or maybe urban legend) to load 4 blocks:
If the test CD mainly contained the boot image, then load size 4 would
pull 8 kB which might well have been in the readable range of the CD
because the boot image is much larger.
But reading four times the boot image size might have exceeded the CD
size or a halfways reasonable size limit of the buggy BIOS.

Don't laugh. A similar urban legend surrounds reading the end of a CD.
If the CD was burned with write type TAO, then some drives tell 2 data
blocks too many when inquired by READ CAPACITY. Some tell the truth.
Linux buffered read inflated the bug range to about 64 kB within the
real end of the CD payload.
Now it was obscure enough so that the cdrtools community mistook this
large range as the 2 seconds of TAO track gap on CD. (It is actually
about the two "run-out" blocks at TAO track end.)
So mkisofs, its clone, and its emulator by default add 2 seconds = 300 kB
of padding to any ISO. It has to be feared that some software meanwhile
relies on this.

BenLunt wrote: both BIOSes loaded more than 4 sectors.

One should test with realistic sizes for a boot image. A few dozen kB
seem appropriate.
isolinux.bin has 40960 bytes, GRUB2 eltorito.img has 27874.


Have a nice day

Thomas

Hi,

Brendan wrote:For old computers (e.g. the 80486 I had, where El Torito didn't even exist when the firmware was written); which of these options do you think is "less ugly" for the end user:

• It's impossible to boot/install the OS
• You need a set of many floppy disks, where running the OS directly from many floppies is completely impractical, and installing the OS from many floppies involves prompting the user to change floppy disks many times ("Please insert disk #12 to continue installing").
• Expect the end user to remove the hard drive and plug it into a different computer, and provide a kind of "cross installer" (e.g. that bypasses the normal "autodetect what needs to be installed" stuff because the computer the OS is being installed on is different to the computer the OS going to be booted on).
• Put a floppy disk image on the installation CD so that the end user can create a boot floppy (on any OS, on any computer); where that boot floppy contains a minimal version of the OS with little more than CD drivers; where the user boots from floppy and everything else needed to boot or install the full OS comes from the CD.

Of these four solutions, the last one is the least ugly. Then comes the second one, then the first, then the third. But still they are all ugly.

Brendan wrote:Note: If you don't care about ancient computers (that may not support El Torito at all), then you probably have no reason to care about ancient computers (where El Torito exists but is buggy) either.

We can't know that only ancient computers have buggy support for El-Torito. It could be that some recent computers fall to the list of broken El-Torito implementations too.

I think I will check for a magic number at offset 0x800 and just load the rest using the El-Torito boot entry if the number at offset 0x800 is not correct (and possibly display a debug message depending on assembling options). There are concerns though that the value at that address might be equal to the magic number without actually the boot file to be loaded fully (uninitialised memory can contain anything).

Still, if one of my users encounters a broken El-Torito implementation I will post about it.


Regards,
glauxosdever

I'd write the MD5 or SHA256 checksum of the previous bytes to the end of the
boot image. This will not only prevent accidentially recognized magic with a
high degree of certainty, but also can serve as check whether the boot image
file in the ISO is a perfect copy of the prepared one on hard disk. (In case of
bug reports such a check often comes in handy.)