OSDev.org

Hi,


I'm wondering whether did anyone come across BIOSes that wouldn't load the entire boot file from a no-emulation El-Torito cdrom (and would unconditionally only load the first 2048 bytes). If there are such BIOSes, it would be handy for many people to have a list of them.


Regards,
glauxosdever

If I remember correctly, the count in the boot entry is a count of 512-byte sectors, not 2048-byte sectors.

Therefore, if you place a count of 4 (four) in the "sector count" field, the BIOS will only load 2048 bytes, or 1 sector from a CD-ROM. If you want it to load 4 sectors, you need a count of 16.

However, this is all from memory, so please verify before you take it as fact.

Ben
http://www.fysnet.net/osdesign_book_series.htm

Hi,


I think you misunderstood the point of this thread. I was asking whether you came across any BIOSes that ignore the field specifying the count of sectors to load and always load 2048 bytes instead.

Someone in the bug-xorriso mailing list has said that some BIOSes can't handle any other sizes apart 2048 bytes. This means that specifying a load size other than 2048 is not really portable.

For reference, here is the relevant email.

Regards,
glauxosdever

Hi,

that someone is me, the developer of xorriso.
I remember to once have wondered why ISOLINUX, GRUB, and other bootloaders
all let BIOS load only 2048 bytes and take the plight to let the loaded
code fetch the rest.

It might well be, of course, that the bootloader developers already had
lean code for that purpose from their work on MBR booting.

Have a nice day

Thomas

Hi,

glauxosdever wrote:I'm wondering whether did anyone come across BIOSes that wouldn't load the entire boot file from a no-emulation El-Torito cdrom (and would unconditionally only load the first 2048 bytes). If there are such BIOSes, it would be handy for many people to have a list of them.

I'd be quite sure that someone came across this problem once upon a time. The real question is not "what" (the name/s of the BIOSes that were effected) - if you know at least one computer is effected then you implement a work-around, and once you have a work-around you have no reason to care which computers are effected. The real question should be "when".

For all specifications (El Torito, ACPI, UEFI, etc) the first few implementations are almost always relatively dodgy. El Torito first appeared in 1995, so you'd expect that dodgy implementation of El Torito would have been much more common in computers from the late 1990s. Hopefully, after about the year 2000 bugs in firmware would've mostly been fixed and we'd be left with people saying "don't do this because it was broken in the recent past (and therefore effects computers people are still using now)".

If you assume that the problems where from computers made in the late 1990s; then you'd have to decide if you still care about these old computers. For example; if your OS only supports 64-bit systems then you probably have no reason to care at all.

For work-arounds; making sure the boot loader is 2 KiB (or smaller) is one way, but that usually means having a second stage and having to find that second stage within the (ISO9660) file system and dealing with a wider range of possible problems before you have the majority of your boot code in memory (and before you've setup robust error handling that's able to deal with the wider range of possible problems).

For an alternative; I usually put some kind of magic number at offset 2048 in my boot loader, then do "if my magic number is not present, load the missing part of boot loader; then overwrite the magic number" early in the boot loader. This means that people with correct firmware aren't penalised with extra disk seeks, etc; and for dodgy firmware it means I can use the "El Torito boot entry" to find the sectors that should've been loaded but weren't (and don't need to worry about ISO9660 until I know the full boot loader is present, and don't need to split my boot loader into 2 stages). This alternative would also allow you to gather info about how common the problem still is.


Cheers,

Brendan

glauxosdever wrote:I think you misunderstood the point of this thread. I was asking whether you came across any BIOSes that ignore the field specifying the count of sectors to load and always load 2048 bytes instead.

No, I understood what you were saying, I just wanted to make sure that you weren't telling the BIOS to read four sectors and expecting four 2048-byte sectors to be read when only one 2048-byte sector was read.

I agree with Brendan's "For an alternative;" statement. Place a magic number somewhere past then 2048-byte offset. If not found, read in the boot entry, calculate, and read in the remaining sectors.

However, for your question; No, I have not come across any BIOSes that only read the first 2048-byte sector.

Ben

P.S. I now had some time to go look through the specification. It looks to me as the count at offset 0x06 is the count of "emulated" sectors. Therefore, if you are emulating a 1.44meg floppy, a count of 2 will read 1024 bytes, or half a (CDROM) sector. If there is no emulation, then I take it as a count of 2 will read 4096 bytes, two 2048-byte sectors. Someone please correct me if I am wrong.

(This assuming the block size of the media is 2048 bytes)

Thanks,
Ben

For practically complete coverage, do what Windows 98, 2000, and XP do. I cannot check it but for some reason "four sectors" is stuck in my mind. I may be wrong and this has to be verified from some source.

Some other thoughts,

• Some early implementations may support the diskette emulation but not the actual no-emulation mode. Again, the source is unknown but I noted this down when I did some researching a few years ago.
• Are we assuming that some implementations may simply skip loading the sectors above 4 but correctly load the first ones? Or would it be possible that the whole boot fails? Then there nothing boot code can do, i.e. it is not given a chance to execute at all.
• Crossing segment boundaries, i.e. 0x0FFFF to 0x10000 or 0x1FFFF to 0x20000. This is just an opinion but I am pessimistic about this. It could work just fine but sounds like "choosing the untested code branch."
• Other bases than 0x00007C00. Same as above.

Mostly this means that "be careful" because if Windows CD (for example) boots but your does not boot then there is only the "making excuses and technical jargon" option left when you explain the problem to your end users.

Hi,

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

1.5. Definition of terms says:
"Sector - Is a sector of data on a CD. This is in all cases 800 bytes.

Virtual Sector - Is a sector of data on an emulated device.
This document only addresses 200 byte device (for emulation)"

1.2 says
"All numbers in this document are hexadecimal unless otherwise specified."

So "800" and "200" are hex numbers. Decimal they are 2048 and 512.

Figure 3 says:
"6-7, Word, Sector Count.
This is the number of virtual/emulated sectors the system
will store at Load Segment during the initial boot procedure."

Although the figure talks of "emulated", there is a statement in 4.3 :
"When the boot image is simply a “loader” or stand alone program,
and NO EMULATION is desired, the drive numbers will be unaffected
after the boot image is loaded. The specified number of sectors are
loaded at the specified segment (usually 7C0), and then the BIOS
jumps to the load address."

Actually i cannot spot any reference to Sector Count with the modes which
emulate a floppy or a hard disk on CD.

I my collection of ISOs, the only ones which have not Sector Count 4
are firmware images which either use Hard Disk emulation or 1.4 MB Floppy
emulation. Their Sector Count is 1.

Have a nice day

Thomas

Hi,

Brendan wrote:The real question is not "what" (the name/s of the BIOSes that were effected) - if you know at least one computer is effected then you implement a work-around, and once you have a work-around you have no reason to care which computers are effected. The real question should be "when".

You are quite right. However, getting a sample of BIOSes that wouldn't behave correctly would provide some evidence about "when" too.

Brendan wrote:For work-arounds; making sure the boot loader is 2 KiB (or smaller) is one way, but that usually means having a second stage and having to find that second stage within the (ISO9660) file system and dealing with a wider range of possible problems before you have the majority of your boot code in memory (and before you've setup robust error handling that's able to deal with the wider range of possible problems).

I thought of using the Boot Information Table, which is a convention used by bootloader developers. So I would load the rest of the boot file without ISO9660 file system handling.

Brendan wrote:For an alternative; I usually put some kind of magic number at offset 2048 in my boot loader, then do "if my magic number is not present, load the missing part of boot loader; then overwrite the magic number" early in the boot loader. This means that people with correct firmware aren't penalised with extra disk seeks, etc; and for dodgy firmware it means I can use the "El Torito boot entry" to find the sectors that should've been loaded but weren't (and don't need to worry about ISO9660 until I know the full boot loader is present, and don't need to split my boot loader into 2 stages). This alternative would also allow you to gather info about how common the problem still is.

This is also an option, but I think it is overly complex. The bootloader will only run once anyway.

Antti wrote:For practically complete coverage, do what Windows 98, 2000, and XP do.

This looks like a good option since most BIOS manufacturers only test if Windows boots.

Antti wrote:Some early implementations may support the diskette emulation but not the actual no-emulation mode. Again, the source is unknown but I noted this down when I did some researching a few years ago.

I was specifically talking about the no-emulation mode, but again, misbehaving diskette and hard disk emulation cases would be interesting to be known too.

Antti wrote:Are we assuming that some implementations may simply skip loading the sectors above 4 but correctly load the first ones? Or would it be possible that the whole boot fails? Then there nothing boot code can do, i.e. it is not given a chance to execute at all.

Actually, both cases matter. In the latter case, boot code can't do anything, but the ISO image generator could simply prevent that if the latter case is existent.


Regards,
glauxosdever

glauxosdever wrote:

Antti wrote:Some early implementations may support the diskette emulation but not the actual no-emulation mode. Again, the source is unknown but I noted this down when I did some researching a few years ago.

I was specifically talking about the no-emulation mode, but again, misbehaving diskette and hard disk emulation cases would be interesting to be known too.

I did not mean misbehaving diskette and hard disk emulation cases (that may exist also) but possibly unsupported no-emulation cases (that may sound surprising). Supporting the no-emulation mode is by far the most sensible choice, however. I chose this no-emulation mode with a one-sector (512 bytes) first stage boot loader that is responsible for "starting the boot process."

The first stage does not need to support ISO 9660, just like you suggested.

Hi,

glauxosdever wrote:

Brendan wrote:For work-arounds; making sure the boot loader is 2 KiB (or smaller) is one way, but that usually means having a second stage and having to find that second stage within the (ISO9660) file system and dealing with a wider range of possible problems before you have the majority of your boot code in memory (and before you've setup robust error handling that's able to deal with the wider range of possible problems).

I thought of using the Boot Information Table, which is a convention used by bootloader developers. So I would load the rest of the boot file without ISO9660 file system handling.

The Boot Information Table is a non-standard hack designed by fools that were too stupid to do anything right and willing to circumvent the established standardisation process. Relying on it will cause everything to break under various circumstances. For example, using tools (that do comply with all actual standards) to obtain an image from a CD, add some files to the image, then write the new image to a CD can/will cause the "LBA of Boot File" to be wrong.

glauxosdever wrote:

Brendan wrote:For an alternative; I usually put some kind of magic number at offset 2048 in my boot loader, then do "if my magic number is not present, load the missing part of boot loader; then overwrite the magic number" early in the boot loader. This means that people with correct firmware aren't penalised with extra disk seeks, etc; and for dodgy firmware it means I can use the "El Torito boot entry" to find the sectors that should've been loaded but weren't (and don't need to worry about ISO9660 until I know the full boot loader is present, and don't need to split my boot loader into 2 stages). This alternative would also allow you to gather info about how common the problem still is.

This is also an option, but I think it is overly complex. The bootloader will only run once anyway.

As long as you make an informed choice between "less complex/worse" and "more complex/better" and accept the consequences; that's fine.

In my opinion, this alternative is not complex enough (e.g. doesn't provide any kind of redundancy in case the CD is scratched, etc).

Antti wrote:

• Some early implementations may support the diskette emulation but not the actual no-emulation mode. Again, the source is unknown but I noted this down when I did some researching a few years ago.
• Are we assuming that some implementations may simply skip loading the sectors above 4 but correctly load the first ones? Or would it be possible that the whole boot fails? Then there nothing boot code can do, i.e. it is not given a chance to execute at all.

Some systems have CD, but don't support booting from CD in any way at all (I used to own an 80486 that was like this). My work-around for this is to support booting from floppy initially, loading CD drivers from floppy, then getting everything else from CD. I also like to put a suitable floppy image on the CD to make it easier for end users to create the floppy if they ever need to.

The same "boot from something else initially, then get remaining files from CD later during boot" idea would also work-around other possible problems.


Cheers,

Brendan

Hi,


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.

That's not to say that the Boot Information Table is perfectly ok, loading the whole boot file is much more preferable. On the other side there are people that say that some BIOSes won't behave properly when they need to load the whole boot file, however they don't say which are those BIOSes. The point of this thread is to identify them. And this information is useful, not only for me, but also for other developers that write boot loaders for cdroms.


Regards,
glauxosdever

Hi,

glauxosdever wrote: BIOSes [which don't] behave properly when they need to load the whole boot file
[...] The point of this thread is to identify them.

El Torito "NO EMULATION" images for BIOS with load sizes other than 4
seem to be extremely rare. So hardly anybody will have experience with them.

The best you can do is to prepare a test CD and try it on as many machines
as you can. Maybe you should offer its ISO image for download, so that
others can test their oldest iron.

Its boot image code should really depend on all blocks being properly loaded.
Therefore we cannot use an ISO with a boot image which has load size 4. Even
if we patch or repack the ISO to have full boot image size as load size.

Have a nice day

Thomas

Antti wrote:I chose this no-emulation mode with a one-sector (512 bytes) first stage boot loader that is responsible for "starting the boot process."

After reconsidering the issue, my previous design is not good. Reading 4 emulated sectors could be safer than reading one emulated sector. The reasoning: 4 emulated sectors and one real sector are a perfect match. If I made a simple file system parsing fit into 2048 bytes and read the next stage from a file, it would be the most "standards-compliant."